我来自SVN背景，所以我不确定典型的git工作流程是什么样的。合并SVN时，提供描述合并的提交消息。这是必要的，因为SVN的合并跟踪在历史上一直很差。
我注意到git的默认行为是如果成功则自动提交合并的结果。这意味着日志通常不会显示合并，因此历史记录中的所有内容看起来都是在一个分支中开发的。这是否更适合将合并显示为额外提交？我可以想出几个原因以及原因，但我想要其他用户的一些意见。
答案 0 :(得分：7)
我认为你错了两种情况（或者我不明白你在问什么）。
如果您合并了一个分支，它是您当前所在分支的直接子分支，则会导致所谓的快进情况。普通的git不会创建合并提交，只是提前分支提示，但你可以使用--no-ff选项阻止它。
默认是避免这种无意义的合并，因为它在真正的分布式开发中表现得更好。
如果您所在的分支和正在合并的分支是真正分歧的，即每个分支上的提交都不在其他分支上，git会进行合并，如果它可以进行合并没有冲突，它会自动创建合并提交。这样的合并提交将具有自动提交消息，受merge.log配置变量（以前为merge.summary）的约束。您可以使用--no-commit选项阻止这样的自动提交。
当然“git log”会显示合并提交，除非你使用“git log --no-merges”。
我希望这个解释会有所帮助。
答案 1 :(得分：5)
除非您向--no-merges提供git log选项，否则它通常会显示合并，并给出简短的自动生成提交说明。
这通常很好，因为git记录了提交的父级，合并的有趣功能是它的组成分支。
尝试使用git log --graph --oneline或使用图形历史记录查看器，您可能（应该！）确信git记录合并的方式比冗长的合并提交消息更重要和有用。
合并只需要一个详细的提交消息，如果在解决方案中有一些“魔法”。因为这意味着手动干预，所以此时很容易添加。