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

Thi*_*Not 4 svn git merge commit

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

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

Jak*_*ski 7

我认为你错了两种情况(或者我不明白你在问什么).

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

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

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

    当然"git log"会显示合并提交,除非你使用"git log --no-merges".

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


CB *_*ley 5

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

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

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

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