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

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

合并后的图形：

---

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

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

当您合并两个分支（例如“开发为主分支”）时，您有三个选择：

如果开发中已经存在对master的所有提交，则只需将master的分支指针移动到与开发相匹配的位置，而无需创建任何新的提交。这是一个“快进合并”

您可以创建一个新的commit，它的父级为developer和master。所有在发展历史中的承诺现在也在大师的历史中

您可以将两个分支之间的所有差异“挤压”到一个提交中，仅将master作为其父级。来自develop的所有更改现在都将在master上进行，但构成这些更改的所有提交都不在master的历史中

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

这一课是只在以后要丢弃的分支上使用挤压合并。例如，您处理的每个任务都可以位于新的分支中；您可以从当前的“开发”（或“主控”、“主控”或“任意位置”）状态启动它，挤压合并它，然后删除分支。下一个任务再次从develope/master/main开始，而不是从旧的任务分支开始，因此您挤压掉的旧提交不再重要

---

或者（以及我个人的偏好），不要使用挤压合并。让每次提交都有意义，使用

git-rebase-i

和

git-commit-amend

来整理您不希望在历史记录中出现的愚蠢错误（注意只重写您没有与其他用户或其他分支共享的历史记录），然后使用快进合并或合并提交。

这是意料之中的。挤压提交将生成新的提交。Hello@DanielMann。所以你建议不要挤压吗？我想保留我的开发分支以备将来的开发，但我不希望出现意外的差异。如果您合并到master的唯一分支是develop，那么在这种情况下，您可以毫无问题地使用rebase/fast forward nerges。（如果希望复制所有提交）