Question

当您将两个分支合并在一起时，git会创建一个单独的提交，其中包含Merge branch 'master' into my-branch之类的消息。对于非平凡的合并，我很清楚这很有用：它将事物合并的历史记录与任何其他更改分开。但是当合并很简单时（例如，当两个分支不影响任何共同的文件时），单独合并提交的目的是什么？

您可以使用git merge --no-commit来避免该提交。然后，您也可以在此提交中添加“真实”更改。这样你就可以避免看似毫无用处的额外提交。但是该手册页警告说：

您应该避免滥用此选项以将重大更改隐藏到合并提交中。像碰撞版本/版本名称这样的小修正是可以接受的。

为什么？

提交真实更改标记为o且仅合并提交为X，这是两种情况之间的差异：

o---o-o-o---o--- master
 \   \   \   \
  o-o-X-o-X-o-X-o--- my-feature


o---o-o-o---o--- master
 \   \   \   \
  o-o-o---o---o--- my-feature

为什么第一个优先于第二个呢？

PS：假设我的功能是其他人也使用的公共分支，因此 rebase 不是一个选项。

Answer 1

在我的工作场所，“中央”存储库是SVN服务器。我通过git-svn使用git。

SVN（显然）不进行快进合并。因此，为了能够将我的本地历史记录复制到服务器，我将使外部可见的所有合并显式化。

在一般情况下你更喜欢这种模式的原因（澄清：“你为什么要为两个分支的主要组合提供明确的合并提交，例如长期边功能分支的重新统一，即使这两个分支也是如此不冲突？“）是因为它使存储库更好地反映了所执行的一系列实际操作 - 也就是说，历史的抽象更好地反映了现实那段历史。

当你快进时，关于何时发生整合的信息就会丢失 - 历史中没有任何意义说“这是当X变为Y”时带有相关信息。

这就是为什么有些人甚至为他们当地的分支机构使用合并优先于变基的方式 - 变基是历史重写的一种形式，是纸上的白纸。

对于你的另一个问题 - “为什么只应该在合并提交中进行小的更改”，答案是合并提交可能对其父项的任何或全部都有很大的差异。因此，如果您在其中放置了重要的其他工作，则很难解开问题是集成问题还是您添加的新更改之一。如果您将提交放在父项之一上或合并之后，将二等分更简单，可以进行更改的切换，您可以在不丢失功能的情况下反转合并，等等。

Answer 2

我认为有几个原因可以让单独的合并提交是一个好主意，但这一切都归结为基本规则，即每个提交都应包含属于一起的更改。

您可以从单独的合并提交中受益的可能情况：

您正在尝试找出哪个提交引入了错误。如果你没有分离合并和正常提交，很难弄清楚合并是否会导致该错误，或者是否提交了该提交的实际更改。
您想要还原提交所做的更改。当您还原作为合并的提交并且还包含其自身的更改时应该发生什么？您想仅恢复更改，还是只恢复合并，或两者兼而有之？如果只有其中一个，如何将它们分开？

作为额外的好处，您可以获得更容易理解的历史记录。（如果您使用rebase，您可以获得更容易理解的历史记录，但您说这是不可能的。）

在git中单独合并提交的目的是什么？

2 个答案: