开发部门在使用Gitlab MR合并成为硕士之后就落后了。

Question

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

合并后的图表：

​

为什么合并后的主分支会领先于发展？这是预期的行为吗？我正在使用Gitlab 12.9。我想保留开发部门的未来发展，但我想避免不必要的差异，以显示。

Answer 1

实际上，git只有一种跟踪历史的方法:每个提交都有零或多个父级。通过追溯从提交到它的父母及其父母，git可以确定提交在提交的历史中是什么。

当你合并两个分支，比如说发展成为大师，你有三个选择：

1. 如果主服务器上的所有提交都已在开发中存在，则只需移动主服务器的分支指针以匹配开发，而无需创建任何新的提交。这是一个“快速合并”。
2. 您可以创建一个新的提交，它以开发和掌握为父级。
3. 可以将两个分支之间的所有差异“压缩”为一次提交，只有master是它的父级。开发中的所有更改现在都将在主版上进行，但是组成这些更改的所有提交都不存在于master的历史中。

当您下一次请求合并相同的分支时，git将查找在开发中存在但在主服务器上不存在的提交。如果您选择了选项3，那么所有这些提交都压缩了来自该类别的更改。

教训是，只使用壁球合并在树枝上，你以后要扔掉。例如，您所处理的每个任务都可以处于一个新的分支中；您可以从当前的开发状态(或主任务、主任务或其他任务)开始，压缩合并它，然后删除分支。下一个任务再次从develop/master/main开始，而不是从旧的任务分支开始，因此旧的提交--您压掉的--不再重要了。

或者(和我个人的喜好)，不要使用壁球合并。让每个提交都有意义，使用git rebase -i和git commit --amend来清理历史记录中您不想要的愚蠢错误(小心地只重写没有与其他用户或其他分支共享的历史记录)，然后使用快速转发合并或合并提交。