在Git中尽可能多地提交或尽可能少的提交是否更好？

Question

我最近与一位同事进行了辩论，他坚持认为，由于合并冲突，尽可能少的提交会更好。我认为通过使用尽可能多的提交来获得的细节越多越好。

提交更多或更少的提交是否更好？为什么？

Answer 1

如果你的同事不鼓励许多提交，因为这会以某种方式导致更多的合并冲突，那么这是不正确的，单独的提交数量与合并冲突无关。如果将一个分支合并到另一个分支时代码会发生冲突，那么无论该分支有1个提交还是1,000个分支都无关紧要，这将导致冲突。

这是因为，通常，Git只比较每个分支上的代码 在最终提交 的状态，以及它们之间的“最佳”共同祖先（由合并算法确定）。在祖先和分支的提示提交之间的任何中间提交都不会被考虑。

也就是说，当您与其他人分享您的历史时，您可能希望在您的提交详细到足够有用之间取得平衡，但也要足够稀疏以呈现清晰，易于理解的历史记录。有时您的所有分支需求都是1提交以清楚地显示更改历史记录，有时您可能需要更多。无论是这样还是另一种方式都是情境化的。

如果你只是私下在分支机构工作，你可以随心所欲地提交，无论你想要什么，因为在你与其他人分享你的变化之前，你总是可以在以后重写你的历史更短更清楚。

Answer 2

提前提交，经常提交。 Good article on this topic by Seth Robertson.

我不明白对合并冲突的恐惧很少提及。提交越大，合并冲突的可能性越大，解决的难度就越大。

Answer 3

尝试并提交一个逻辑工作块。以下两个提交消息都是不良做法：

更正了功能X中的拼写（特别是上次提交时与X相关）

更新了功能X的文件，删除了虚假文件并添加了一些不相关的文件

没有人阻止你每隔几分钟或每周一次的工作。但是如果你想要一个干净，可读的历史记录，最好经常提交并在推送你的更改之前将相关的提交压缩成更有意义的提交。