在使用Gitlab MR将Develop分支合并到主分支后，Develop分支落后于主分支

我使用GitLab合并请求将一些更改从develop分支合并到master分支，并压缩了提交。合并后，我比较了两个分支，发现显示错误的差异。由于它们在合并后是相同的，所以我希望没有差异。我检查了提交图表，发现develop分支和master分支现在已经断开连接。

合并后的图表:

为什么合并后master分支超前于develop分支？这是预期行为吗？我正在使用Gitlab 12.9。我想保留develop分支进行未来的开发，但我想避免不必要的差异出现。

- Jiji

这是预期的。压缩提交会创建一个新的提交。 - Daniel Mann

你好@DanielMann。那么你建议不要压缩吗？我想保留我的开发分支以供将来开发，但我不希望出现意外的差异。 - Jiji

如果你只将develop合并到master分支，那么在这种情况下，你可以进行rebase/fast-forward合并而不会出现问题。（如果你想要复制所有提交） - dan1st

基本上， Git 只有一种追踪历史的方式：每个提交都有零个或多个父提交。通过从提交到其父提交的反向跟踪，以及它们的父提交，Git 可以确定哪些提交在该提交的历史记录中。

当您将两个分支合并时，例如将 develop 分支合并到 master 分支，您有三个选择：

1. 如果 master 上的所有提交已经存在于 develop 上，则可以仅将 master 分支指针移动到与 develop 匹配的位置，而不创建任何新提交。这是一个“快进合并”。 2. 您可以创建一个新的提交，其父提交既包括 develop 也包括 master。现在，develop 历史记录中的所有提交也在 master 的历史记录中。 3. 您可以“压缩”两个分支之间的所有差异为一个提交，只有 master 作为其父提交。现在，develop 中的所有更改都在 master 上了，但是组成这些更改的所有提交都不在 master 的历史记录中。

当您下次要求合并相同的分支时，Git 将查找在 develop 上存在但不存在于 master 上的提交。如果您选择了选项 3，则所有那些您压缩了更改的提交仍然属于该类别。

教训是只在您打算之后丢弃的分支上使用压缩合并。例如，您每个任务都可以在一个新分支中工作；您从 develop（或 master、main 或任何其他地方）的当前状态开始，进行压缩合并，然后删除该分支。下一个任务重新从 develop/master/main 开始，而不是从旧的任务分支开始，因此您压缩掉的旧提交不再重要。

或者（也是我个人的首选），不要使用压缩合并。使每个提交有意义，使用 `git rebase -i` 和 `git commit --amend` 来清理您不想在历史记录中出现的愚蠢错误（注意仅重写您尚未与其他用户或其他分支共享的历史记录），然后使用快进合并或合并提交。