关于 git 如何工作的一些注意事项（非技术性）：
当您变基时，git 会获取有问题的提交，并在干净的历史记录之上“重新提交”它们。这是为了防止历史记录显示：
Description: tree -> mywork -> merge -> mywork -> merge -> mywork -> merge
Commit SHA1: aaaa -> bbbb -> cccc -> dddd -> eeee -> ffff -> gggg
变基后，它可能看起来像这样（或类似）：
Description: tree -> rebase
Commit SHA1: aaaa -> hhhh
问题是您尝试推出的新提交是不是后裔您要推送到的分支顶端的提交。
现在，您知道提交中包含相同的信息，但 git 负责的不仅仅是覆盖那些提交（上面示例中的 bbbb-gggg）。
共享回购模型
如果您使用共享存储库，那么类似的事情可能会变得非常混乱。让我解释一下原因。假设另一个开发人员拉下了分支，并且他们已经提交了啊啊-> gggg在他们的分支机构。然后他们做出承诺iiii
与此同时，您重新设置基础并强制推送，导致树看起来像这样：
Description: tree -> rebase
Commit SHA1: aaaa -> hhhh
当其他开发人员尝试推动时，他会收到“非快进”消息。当他进行合并时，两个历史都会重新链接在一起，最终会得到一个mess
像这样的东西（凌乱）：
Description: tree -> rebase -> mywork -> merge -> mywork -> merge -> mywork -> merge -> devwork -> merge
Commit SHA1: aaaa -> hhhh -> bbbb -> cccc -> dddd -> eeee -> ffff -> gggg -> iiii -> jjjj
换句话说，如果其他人正在拉动和推动，那么您最好坚持使用 git merge，或者避免推动直到变基之后（并且仅变基您的工作）。
公开可见的存储库模型
也许您正在使用不同的（更愚蠢的）模型，您只是希望人们能够从您的存储库中提取数据。在这种情况下， git push --force 还不错，因为这样他们就可以跟上它。他们可以重新设定基础他们的改变在将补丁提供给您之前了解您的更改。它可以防止你的仓库变得混乱。
但是，可能有更好的方法适合您。git push --镜像
来自http://www.kernel.org/pub/software/scm/git/docs/git-push.html
不是命名每个要推送的引用，而是指定下面的所有引用
$GIT_DIR/refs/ （其中包括但是
不限于裁判/负责人/，
refs/remotes/ 和 refs/tags/) 是
镜像到远程存储库。
新创建的本地参考将是
推送到远程端，本地
更新的参考文献将被强制更新
远程端，删除的引用将
从远端删除。这
如果配置为默认值
选项远程..镜像已设置。
其中最棒的事情之一git它非常灵活，允许许多不同类型的工作流程。但它真正的优势在于它是一个分布式模型，所以我相信通过这种方式使用它可以获得最大的投资回报率。
