情况如下:( P表示此处的人）。
P1和P2从master创建了自己的分支devP1和devP2。 P2刚刚结束他的工作，所以他与当地的主人合并，然后他推动了远程主存储库。一切都很好。
然而，P1也结束了他的工作，所以他做了同样的事情，与当地的主人合并，然后尝试推动。但很明显，远程大师比他当地的大师领先，他不能推。
在这种情况下，我曾经在这种情况下拉动主分支，但有人最近告诉我这非常糟糕，因为我创建了一个合并提交，其中一个是无关紧要的，或者至少是毫无意义的。
那是他失去我的时候，我无法理解在这种情况下我应该做些什么。有人可以向我解释这里要做什么吗？某种变化可能是什么？但我不能真正改变远程分支吗？
感谢您的帮助和解释。我无法在任何地方找到它。
答案 0 :(得分：1)
我怀疑你的对话者实际上是在使用git rebase而不是合并。考虑下面的简单图表，它将演示什么是rebase。
master: ... A -- B -- D
local: ... A -- B -- C
上图试图表示P1试图推动他的工作时分支的状态。他的local分支和远程master在提交B之前都是相同的。但是P2已将提交D推送到master之上，然后P1在本地提交了C。如果P1要拉远程master，合并然后推送，我们将得到以下图表：
master: ... A -- B -- D -- M'
local: ... A -- B -- C -- M
现在我们看到local和远程master分支都有合并提交（标记为M和M'）。但是，这里有另一种选择。 P1可以通过以下方式在远程master分支上重新他的本地分支：
git checkout local
# do a fetch if not up to date already
# git fetch origin
git rebase origin/master
现在这是图表在变基后的样子：
master: ... A -- B -- D
local: ... A -- B -- D -- C' (C' labelled as such because it is a new commit)
请注意这里，因为重新定位的是回滚 local分支到它自己和master之间的最新公共提交，即提交{{1 }}。然后，它重放来自B的提交，在这种情况下只提交master。最后，它应用D分支唯一的提交，在这种情况下提交local。
你可以希望看到的关于这一点的好处是C现在可以做一个正常的P1来将他的提交带到远程git push：
master这将使图表看起来像这样：
git push origin master
现在远程master: ... A -- B -- D -- C'
local: ... A -- B -- D -- C'
分支上没有合并提交。
请注意，重新定位通常涉及将历史记录重写为分支，如果重写的分支已经公开共享，则可能会出现问题。在master的情况下，如果他的P2分支仅由他使用，那么对其进行重新定位不会受到惩罚。远程local分支没有被我们上面的练习重写。但情况可能并非总是如此，并且需要牢记。
答案 1 :(得分：0)
据我所知，你有两个选择： 1.拉主控，将devP1合并为主控并推送主控。 2.获取devP2。将devP1重新引导到devP2。将devP1合并为master和oush master。
编辑： P1也可以这样做。硬复位主机恢复原状。拉大师。将devP1重新引入主服务器。将devP1合并为master并推送master。
答案 2 :(得分：0)
您可以不与本地主人合并，而是与远程主人合并
git fetch --all
git merge origin/master <--no-ff>
或者你可以改变你的工作，这可以通过pull来完成
git fetch --all
git rebase origin/master
如果您有合并每个分支并且与远程分支合并的规则，但是有人仍然比推送速度快，您可以重置上一次合并并再次执行
git reset --hard HEAD^
git merge....
git push origin master
有很多方法可以做到这一点。没有正确的方法。有些公司强制执行以下规则：您必须使用--no-ff将所有更改合并到master，有些公司更喜欢使用rebase。 Botw的方法是正确的，区别在于你可以从git历史中看出来。
如果出现任何问题，您不必记住之前提交的内容。您始终可以运行git reflog。
PS：git pull只是git fetch --all && git merge ...或git pull --rebase的{{1}}的快捷方式