频繁和少量提交是否有助于git合并？

Question

我们在项目中使用git。具有功能分支的标准工作流程已合并回master。可悲的是，要素分支的变化往往比人们希望的更大（更改了许多行），这会引起偶尔的冲突。

Q1：频繁提交（提交了许多小的更改）是否有助于自动解决git-merge执行的冲突？如果使用外部工具（例如kdiff3）进行合并，答案是否会改变？

理论是，如果git-merge可以在日志中看到小的增量更改，则它具有解决冲突的更多信息。另一方面，可以想象的是，它将在最终合并中实际看到更多的“过时”冲突。所以：

Q2：执行合并时git甚至会使用有关提交历史记录的信息吗？

Q3：如果使用rebase而不是merge，对Q1，Q2的答案是否都会改变？

我知道，如果提交历史很长并且冲突很早就发生，至少rebase会变得很糟糕。

Answer 1

  

如果使用外部工具（例如kdiff3）进行合并，答案是否会更改？

回答问题的这一部分：有git imerge，确实使用完整的提交历史记录来解决合并冲突，以便至少使手动解决冲突变得容易得多。

这不是像kdiff3这样的合并工具，而是一个脚本，它可以增量执行合并（或变基）。

Answer 2

据我所知，合并期间发生的摩擦来自合并所涉及的两个分支的HEAD之间的差异。也就是说，这两个分支的起始点之间有多少个提交都没有关系，而只是两个分支之间的每个文件中的代码有多不同。

另一方面，重新定价可能是另一回事。变基的性质涉及针对一个新的基础重放一个分支上的所有不同提交，该基础合并了另一分支的提交。例如，如果您有10个提交要重播，并且每个提交中的更改都很小，那么您可能很容易解决每个冲突。这可能与通过合并进行相同的操作形成对比，在合并中可能会有一大堆丑陋的合并冲突。但是，重新定价也可能要付出代价。因为您可能必须重播许多提交，所以您可能还必须修复每个提交中的合并冲突。如果您有数百次提交，这可能变得站不住脚。在那种情况下，大多数人宁愿只做一次合并。

通常，进行提交的一个好的策略是，您应该在完成编码任务中逻辑上合理的部分后提交。一方面，进行过于频繁的提交会导致分支丑陋；另一方面，过于频繁的提交会导致问题（如果您必须还原）。之所以如此，是因为这样一来，很难弄清您已采取的步骤。

Answer 3

Q1：我认为这个问题是指将要素分支合并到master中。无论您是拥有多个原子提交还是语义结构较少的较大原子提交，这都没有任何区别。您从原子提交中获得的好处是在CI中，您会看到哪些更改会导致测试失败。

第二季度：否

第3季度：蒂姆·比格莱森（Tim Biegeleisen）说的话。我还建议您阅读Merging vs. Rebasing

上的Atlassians优秀指南