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

Question

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

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

score 7 · Accepted Answer

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

如果您合并一个侧分支，它是您当前所在分支的直接子分支，则会导致所谓的快进情况。普通 git 不会创建合并提交，而只是提前分支提示，但您可以通过--no-ff选项阻止它。

默认是避免这种无意义的合并，因为它在真正的分布式开发中表现更好。
如果您所在的分支和您正在合并的分支确实存在分歧，即每个分支上都有不在其他分支上的提交，则 git 会进行合并，如果它可以在没有冲突的情况下进行合并，它将自动创建一个合并提交。这种合并提交将具有自动提交消息，受merge.log配置变量（以前merge.summary）的影响。您可以使用选项阻止提交这样的自动提交--no-commit。

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

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

score 5 · Accepted Answer

除非您提供--no-merges选项 to git log，否则它通常会显示合并，并给出简短的自动生成提交描述。

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

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

如果在解析中完成了一些“神奇”的事情，合并只需要一个详细的提交消息。由于这意味着手动干预，此时很容易添加。

2 回答 2