我们在项目中使用 git。非常标准的工作流程，功能分支合并回 master。遗憾的是，功能分支的变化往往比人们希望的要大（很多行发生了变化）——这会导致偶尔的冲突。
Q1：频繁提交（提交大量小更改）是否有助于自动解决 git-merge 执行的冲突？如果使用外部工具进行合并（例如 kdiff3），答案是否会改变？
理论上，如果 git-merge 可以在日志中看到小的增量变化，它就有更多信息来解决冲突。另一方面，可以想象它实际上会看到更多在最终合并中“过时”的冲突。所以：
Q2：git 在执行合并时甚至会使用有关提交历史的信息吗？
Q3：如果我们使用变基而不是合并，Q1、Q2 的答案是否会改变？
我知道，如果提交历史很长并且早期发生冲突，那么至少 rebase 会变得很糟糕。
【问题讨论】：
如果使用外部工具进行合并（例如 kdiff3），答案会改变吗？
回答这部分问题：有git imerge，确实使用完整的提交历史来解决合并冲突，以便至少使手动解决冲突更容易。 p>
这不是像 kdiff3 这样的合并工具，而是一个增量执行合并（或变基）的脚本。
【讨论】：
据我所知，合并期间会发生的摩擦来自合并中涉及的两个分支的 HEAD 之间的差异。也就是说，在这两个分支的起源点之间有多少提交并不重要，而重要的是两个分支之间每个文件中的代码有多么不同。
另一方面，变基可能是另一回事。变基的本质涉及将一个分支上的所有不同提交针对一个新基重放，该新基包含来自另一个分支的提交。例如，如果您有 10 次提交要重播，并且每次提交中的更改都相当小，那么您可能很容易解决每个冲突。这可以对比通过合并执行相同的操作，其中可能存在一大组丑陋的合并冲突。但是，rebase 也可能要付出代价。因为您可能必须重播许多提交，所以您可能还必须修复每个提交中的合并冲突。如果您有数百个提交，这可能会变得站不住脚。在这种情况下，大多数人宁愿只进行一次合并。
一般来说，进行提交的一个好策略是，当你完成了编码任务的一些逻辑上合理的部分时，你应该提交。一方面，过于频繁的提交会导致一个丑陋的分支，另一方面，如果你不得不恢复，过于不频繁的提交可能会导致问题。之所以如此，是因为这样就很难梳理出您已采取的步骤。
【讨论】：
Q1：我认为这个问题是指将功能分支合并到master中。无论您有许多原子提交还是语义结构较少的较大提交，这都没有任何区别。您从原子提交中获得的优势在于 CI，您可以看到哪些更改会导致测试失败。
Q2：否
Q3：蒂姆·比格莱森说了什么。我还建议您阅读 Merging vs. Rebasing 上的 Atlassians 精彩指南
【讨论】：