好的，我镜像了 4 个分支。 其中2个是主要分支。
我想用一个主分支来重定我的一个功能分支。所以我在运行变基命令后这样做了
git push --force
同时让我的功能成为工作分支。
这导致了问题并推送到所有分支，因为我的 git 配置设置是"匹配">
自从这种情况发生以来不久，所以我们能够将所有分支恢复到它们所在的位置。
但是，我现在注意到拉取请求现在显示的提交次数超过了应有的数量。我相信这是灾难的副作用。如何解决这些拉取请求？
如果您确实将存储库分支恢复到灾难发生前的状态，那么在灾难期间没有进行任何拉取的任何人都应该不会有任何问题。在灾难期间，某些开发人员可能从存储库中提取了强制材料。因此，当他们从固定存储库中提取时，他们将再次遇到问题。
在这种情况下要做的是避免git pull命令。重写的历史导致变基和合并陷入混乱，产生不必要的冲突。
每个人都应该做一个git fetch来拿起存储库材料，而不对他们的工作副本做任何事情，然后适当地处理这种情况。
假设我在一个名为 master 的分支上(不损失一般性(。我做了一个git fetch(因为我被告知上游已经重写了历史(，然后输入git checkout以了解损坏情况。我看到如下消息：
您的分支和源/主节点已分道扬镳，并且有 17 个和 25 个不同的提交，或者。
好。因此，这意味着上游历史记录已从 17 个提交点(从我们本地master的 p.o.v. (重写回来。现在，假设我碰巧知道master上的四个提交是我的新的本地提交。 我当然知道这一点，因为当我做git log时，我知道什么是我的！ (另外，我碰巧记得在带来这种混乱的git fetch之前，Git 告诉我我的master领先 origin/master 4 次提交。
如果这是别人的混乱，并且我不知道要保留哪些提交，我会比较
git log和git log origin/master以查看重复的开始位置，并假设master上比重复提交更新的任何内容都是需要保留的宝贵更改。
我所关心的只是保留这四个变化。我想做的是master看起来像重写的origin/master，加上我的四个更改。
有多种方法可以做到这一点。这是一个非常简单的：
git rebase HEAD~4 --onto origin/master
做！我们已经采用了前四个提交，并将它们迁移到origin/master，并将结果放在主分支的位置。(顺便说一句，我怀疑--onto origin/master论点是多余的，因为我们在master，origin/master是它的上游！所以它可以像git rebase HEAD~4一样简单. "把四个提交放入救生艇，然后前往未沉没的船！">
请注意，如果我们做了一个git pull --rebase，那么它将做等效于：
git fetch # master and upstream diverge: 17 versus 25
git rebase # all 17 commits are being rebased over top of the upstream 25, OOPS!
对于 rebase HEAD~4 ，我们将变基的范围限制为只挑选那些我们知道是需要重定基址的提交，而不是在上游 25 个提交中复制的剩余 13 个提交并会导致合并问题。 其余13个被遗弃。 我们的四个变化在origin/master重播，这成为新的master。
请注意，有时天真的变基可以工作！例如，假设 25 次提交的重写历史记录实际上并没有对文件内容进行任何更改，而只是对提交消息、作者和时间戳进行任何更改。在这种情况下，git 可以解决它。这种情况一直在发生，例如，在评论工具Gerrit上。合并提交的 Gerrit 更改后，它们仍位于本地存储库中。当你做一个
git pull，你带来了完全相同的提交的合并版本，但在不同的哈希下。 Git 发现你已经在本地拥有相同的提交，并且它们在变基中消失了。