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

Question

最近我从功能分支 merge 了一个巨大的 pull 请求(140 次提交)到主分支:

我可以在 master 分支的 github 概览中看到 merge :

但是，当我切换到功能分支时，我可以看到该功能提前了 141 次提交(今天我对功能进行了另一次提交)并且在 master 后面进行了 1 次提交:

现在的主要问题是，我无法 merge 我今天对功能所做的更改以掌握:

因为 github 似乎想再次提交已经 merge 的 140 个旧提交(在一些痛苦的冲突解决之后)
我怎样才能再次同步 master 和 feature，所以它们才是真正的样子:它们之间的区别是 仅 从今天开始提交功能。

Answer 1

看起来您正在使用两个长期运行的分支并使用 Squash merge 。这有点问题，这就是原因。
当 Git 执行 merge 时，它会考虑三个点:您要 merge 的两个头，以及第三个点，称为 merge 基础，通常是它们的共同祖先。 merge 的结果是 merge 基和每个头之间变化的总和。
如果您使用正常的 merge 提交 merge 两个分支，那么您将创建一个新的共同祖先，因此 future 的 merge 将从该基础开始。你不必担心已经 merge 的东西的冲突，因为 Git 甚至不考虑它们。
当您通过压缩 merge merge 两个分支时，您会在一个分支上创建一个提交，其中包含另一个分支的所有更改，但不会创建新的共同祖先。结果，当您再次尝试 merge 时，Git 会查看双方的所有更改，最终可能会出现很多冲突。如果您继续挤压 merge 两个分支，情况只会变得更糟。
因此，除非您真的想一直解决大量冲突，否则您确实必须使用正常的 merge 提交来集成两个长时间运行的分支。 Squash merge 在这里不起作用。
如 feature不需要长时间运行，然后只需从 master 重新创建它. Git 非常擅长创建功能分支，一旦它们 merge ，您就可以丢弃这些分支。这是解决这个问题的最简单的方法。由于您有一个需要包含在内的提交，因此只需按照与 eftshift0 概述的步骤类似的步骤操作即可:

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

否则，这是解决此问题的最简单方法。在 master 上提交在你的 Squash merge 之前立即调用它 A .在 feature 上提交你 merge 并称之为 B .

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

这将创建一个名为 temp 的分支看起来和 Squash merge 完全一样，但是有一个真正的 merge 提交，然后将它 merge 到 master .此 merge 是无操作的，因为双方完全相同，因此您不必解决任何冲突。然而，双方现在共享一个新的共同祖先， future 的 merge 可以以此为基础，这解决了这个问题。然后，您可以在集成两个分支时使用正常的 merge 提交。