成功合并后，Github仍显示分支之间的差异

Question

最近，我将一个巨大的请求请求（140次提交）从功能分支合并到了主服务器：

我可以在master分支的github overiew中看到合并：

但是，当我切换到功能分支时，我可以看到该功能提前141次提交（今天我对功能进行了另一次提交），而在master之后进行了1次提交：

现在的主要问题是，我无法将我今天在功能上所做的更改合并到母版中：

因为github似乎想再次提交已经合并的140个旧提交（在解决一些痛苦的冲突之后）

我该如何再次同步母版和要素，因此它们实际上是什么：它们之间的区别是仅从今天开始的要素提交。

Answer 1

您似乎正在使用两个长期运行的分支并正在使用壁球合并。这有点问题，这就是原因。

当Git执行合并时，它会精确地考虑三个点：您要合并的两个头，以及第三个点，称为 merge base ，通常是它们的共同祖先。合并的结果是合并基础与每个头部之间的变化之和。

如果使用正常的合并提交合并两个分支，那么您将创建一个新的公共祖先，因此以后的合并将从该基础开始。您不必担心已经合并的东西带来的冲突，因为Git甚至都不会考虑它们。

当您通过壁球合并合并两个分支时，您会在一个分支上创建一个提交，其中包含来自另一个分支的所有更改，但是您没有创建新的共同祖先。结果，当您尝试再次合并时，Git会查看双方的所有更改，最终会导致很多冲突。如果您一直压扁合并两个分支，这只会变得更糟。

因此，除非您真的想一直解决很多冲突，否则您真的必须使用普通的合并提交来集成两个长期运行的分支。壁球合并在这里不起作用。

如果feature不需要长时间运行，则只需从master重新创建即可。 Git擅长创建要素分支，一旦合并它们就可以丢弃它们。这是解决此问题的最简单方法。由于您需要对此提交进行提交，因此只需按照与概述的eftshift0相似的步骤进行操作即可：

$ git checkout feature
$ git rebase --onto master HEAD^
# optionally:
$ git push origin +feature

否则，这是解决此问题的最简单方法。在壁球合并之前立即对master进行提交，并将其命名为A。在您合并的feature上进行提交，并将其命名为B。

$ git checkout -b temp A
$ git merge B
$ git checkout master
$ git merge temp

这将创建一个名为temp的分支，它看起来像壁球合并，但具有真正的合并提交，然后将其合并到master中。合并是不可操作的，因为双方都是完全相同的，因此您不必解决任何冲突。但是，双方现在共享了一个新的共同祖先，将来的合并可以以此为基础，从而解决了这个问题。然后，在集成两个分支时可以使用普通的合并提交。

Answer 2

就像@matt所说，您可能没有合并，但被压缩或重新设置了内容。然后，您能做的最好的事情就是在基础分支的基础上重新构建单个修订版本：

git checkout feature-branch
git rebase --onto origin/the-base-branch feature-branch~ feature-branch

这会将分支置于基础分支的顶部...如果您使用的是与创建PR之前使用的分支相同的分支，则可能必须强制推动，因为该历史记录不是真正的 < / em>合并到基本分支中，因此正常推送将失败。