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

Question

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

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

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

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

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

我怎样才能再次同步主控和功能，让它们保持原来的样子：它们之间的区别只是从今天开始对功能的提交。

Answer 1

看起来您正在使用两个长期运行的分支并使用挤压合并。这有点问题，原因如下。

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

如果您使用正常的合并提交合并两个分支，那么您将创建一个新的共同祖先，因此将来的合并将从该基础开始。您不必担心已合并内容的冲突，因为 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. 此合并是无操作的，因为双方完全相同，因此您不必解决任何冲突。然而，双方现在拥有一个新的共同祖先，未来的合并可以基于该祖先，从而解决了问题。然后，您可以在集成两个分支时使用正常的合并提交。