好的，我有4个分支镜像。其中2个是主要分支。
我想用主分支来修改我的一个功能分支。所以我在运行rebase命令
之后做了这个git push --force
将我的功能作为工作分支。
这会导致问题并推送到所有分支机构，因为我的git配置设置为＆＃34;匹配＆＃34;
自从这件事发生后不久，我们就能够将所有分支机构恢复原状。
但是，我现在注意到pull请求现在显示的提交次数超出了应有的范围。我确信这是灾难的副作用。如何解决这些拉取请求？
答案 0 :(得分：3)
如果你真正将存储库分支恢复到灾难发生前的状态，那么任何在灾难期间没有做任何事情的人都不应该在做新事情时遇到任何问题。一些开发人员可能会在灾难期间从存储库中取出强制材料。因此，当他们从固定存储库中撤出时，他们将再次遇到问题。
在这种情况下要做的是避免使用git pull命令。重写的历史导致重组和合并与不必要的冲突发生混乱。
每个人都应该git fetch来获取资料库材料，而不对其工作副本做任何事情，然后适当地处理这种情况。
假设我在一个名为master的分支上（不失一般性）。我做了git fetch（因为我已经被告知上游有历史重写），然后输入git checkout来了解损坏情况。我看到一条消息：
你的分支和origin / master已经分歧，并且有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一样简单。＆＃ 34;将四次进入救生艇并前往非沉船！＆＃34;）
请注意，如果我们完成了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，我们将rebase的范围限制为只选择我们知道的那些需要重新提交的提交，而不是那些在其中复制的13个提交。那些上游25并将导致合并问题。其余13人被遗弃。我们的四项更改将在origin/master上重播，并成为新的master。
请注意，有时天真的rebase 可以工作！例如，假设25次提交的重写历史记录实际上并未对文件内容进行任何更改，而只是提交消息，作者和时间戳。在那种情况下，git可以解决它。例如，使用评论工具Gerrit，这种情况一直在发生。当您提交的Gerrit更改合并时，它们仍然在您的本地仓库中。当你执行
git pull时，你会引入完全相同的提交的合并版本，但是在不同的哈希下。 Git知道你已经在本地提交了相同的提交，并且它们会在rebase中消失。