使用 Gitlab MR 合并到 master 后，Develop 分支落后了

Question

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

合并后的图形：

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

Answer 1

本质上，git 只有一种跟踪历史的方式：每个提交都有零个或多个父项。通过从提交到其父项及其父项向后跟踪，git 可以确定该提交的历史记录中有哪些提交。

当你合并两个分支时，比如说开发成 master，你有三个选择：

1. 如果 master 上的所有提交都已经存在于 develop 上，您只需移动 master 的分支指针以匹配 develop ，而无需创建任何新提交。这是一个“快进合并”。
2. 您可以创建一个以 develop 和 master 为父项的新提交。开发历史中的所有提交现在也包含在 master 的历史中。
3. 您可以将两个分支之间的所有差异“压缩”到一个提交中，只有 master 作为其父级。来自 develop 的所有更改现在都将在 master 上进行，但构成这些更改的所有 提交都不在 master 的历史中。

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

教训是只在以后要扔掉的分支上使用壁球合并。例如，您处理的每个任务都可以在一个新分支中；你从当前的develop（或者master，或者main，或者任何地方）状态开始，squash合并它，然后删除分支。下一个任务再次从 develop/master/main 开始，而不是从旧的任务分支开始，因此您压扁的旧提交不再重要。

或者（以及我个人的偏好），不要使用壁球合并。使每次提交都有意义，使用 git rebase -i 和 git commit --amend 整理您不希望出现在历史记录中的愚蠢错误（注意仅重写您尚未与其他用户或其他分支共享的历史记录） )，然后使用快进合并或合并提交。