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

Question

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

合并后的图：

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

Answer 1

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

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

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

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

我们的教训是只在之后要丢弃的分支上使用挤压合并。例如，您处理的每个任务都可以位于一个新分支中；你从开发的当前状态（或master，或main，或任何地方）启动它，压缩合并它，然后删除分支。下一个任务再次从develop/master/main开始，而不是从旧的任务分支开始，所以你压扁的旧提交不再重要了。

或者（也是我个人的偏好），不要使用挤压合并。让每次提交都有意义，使用git rebase -i并git commit --amend清理您不希望在历史记录中出现的愚蠢错误（小心只重写您未与其他用户或其他分支共享的历史记录），然后使用快进合并或合并提交。