为git合并使用单独的提交消息更好吗？

Question

我来自SVN背景，所以我不确定典型的git工作流程是什么样的。 合并SVN时，提供描述合并的提交消息。 这是必要的，因为SVN的合并跟踪在历史上一直很差。

我注意到git的默认行为是如果成功则自动提交合并的结果。 这意味着日志通常不会显示合并，因此历史记录中的所有内容看起来都是在一个分支中开发的。 这是否更适合将合并显示为额外提交？ 我可以想出几个原因以及为什么不这样做，但我想要其他用户的一些意见。

Answer 1

我认为你错了两种情况（或者我不明白你在问什么）。

1. 如果您合并了一个侧枝，它是您当前所在分支的直接子节点，则会导致所谓的快速前进情况。 普通的git不会创建合并提交，只是提前分支提示，但你可以使用--no-ff选项来阻止它。

   默认是避免这种无意义的合并，因为它在真正的分布式开发中表现得更好。

2. 如果你所在的分支和你正在合并的分支是真正的分歧，即每个分支上的提交都不在其他分支上，git会进行合并，如果它可以进行合并而没有冲突，它会自动进行创建合并提交 。 这样的合并提交将具有自动提交消息，受merge.log配置变量（以前称为merge.summary ）的merge.summary 。 您可以使用--no-commit选项阻止这样的自动提交。

   当然“git log”会显示合并提交，除非你使用“git log --no-merges”。

我希望这个解释会有所帮助。

Answer 2

除非你为git log提供了--no-merges选项，否则它通常会显示合并，这些合并会给出一个简短的自动生成的提交描述。

这通常很好，因为git记录了提交的父级，合并的有趣功能是它的组成分支。

尝试git log --graph --oneline或使用图形历史查看器，您可能（应该！）确信git记录合并的方式比长卷合并提交消息更重要和有用。

如果在解决方案中有某些“神奇”的东西，合并只需要一个详细的提交消息。 因为这意味着手动干预，所以此时很容易添加。