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

Question

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

合并后的图表：

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

Answer 1

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

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

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

当您下一次要求合并相同的分支时，git 将查找在开发上存在但在主控上不存在的提交。 如果您选择了选项 3，那么您从其中压缩更改的所有提交仍属于该类别。

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

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