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

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

---

我注意到git的默认行为是在合并成功时自动提交合并结果。这意味着日志通常不会显示合并，因此历史记录中的所有内容看起来都是在一个分支中开发的。这比将合并显示为附加提交更可取吗？我可以想出几个原因来说明原因，但我希望其他用户提供一些信息。

除非您向

git log

提供

--no merges

选项，否则它通常会显示合并，并给出一个简短的自动生成的提交描述

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

尝试使用

git log--graph--oneline

或使用图形历史查看器，您可能（应该！）确信git记录合并的方式比冗长的合并提交消息更重要、更有用

---

只有在解析过程中完成了一些“神奇”的事情时，合并才真正需要一条详细的提交消息。由于这意味着手动干预，因此在这一点上很容易添加。

我认为您误解了两种情况（或者我不理解您的问题）

如果合并当前所在分支的直接子分支，则会导致所谓的快进情况。普通git不会创建合并提交，只会提前分支提示，但您可以使用

--no ff

选项阻止它

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

如果您所在的分支和正在合并的分支确实存在分歧，即每个分支上都有不在其他分支上的提交，git将执行合并，如果它可以执行合并而不发生冲突，它将自动创建一个合并提交。这种合并提交将具有自动提交消息，受

merge.log

config变量的约束（以前是

merge.summary

）。您可以使用

--no commit

选项来防止此类自动提交

当然，“git日志”将显示合并提交，除非您使用“git日志--无合并”

---

我希望这一解释能有所帮助。

当合并发生冲突时，会中止合并提交以让您修复冲突。然后提交，并获得另一条有用的自动生成消息，其中包含有冲突的文件列表。这是添加描述的最常见情况-了解冲突的原因以及如何解决冲突很有帮助。如果没有冲突，简单的自动生成的消息往往是好消息——尽管有些人会添加一个合并到中的功能的快速列表（参见git.git的示例）。将此标记为答案，因为您指出，只有在发生特殊情况时（即手动冲突解决），合并才需要消息。我已经习惯于写SVN中合并的修订范围，所以我认为合并消息在任何地方都是必要的。啊，这就是快进的意思。很高兴知道不那么琐碎的合并有自动提交消息。谢谢你澄清这一点。