version-control - 如何创作不易发生合并冲突的更改？

Question

自动合并并不完美。仅仅因为没有行编辑冲突并不意味着没有句法冲突，这并不意味着没有语义冲突。

有没有人制定低冲突更改的策略？这是从 TDD 或其他方法中脱离出来的吗（当然 TDD 会帮助捕获它们，但它实际上会阻止它们吗）？

Answer 1

我一直发现我的提交越小，它们发生合并冲突的可能性就越小。遇到大问题的人似乎总是会花上几天的时间来解决问题，然后尝试一次将它们全部合并。

现在我正在一个 2 人团队中工作，我们一直在同一个代码库中。我们每个人都在个人分支中工作，然后在有工作时集成到共享分支中。这通常是一天几次。我们几乎从来没有合并冲突，当我们这样做时，它们是非常微不足道的。

所以...经常从存储库中获取最新代码。在您自己的分支中工作，这样您就可以提交您的更改并合并其他人的工作，而不会影响团队的其他成员。然后尽可能频繁地将您自己的代码推送到共享分支，以使更改尽可能小。

另外，与您的团队交谈。如果您知道其他人正在处理特定文件，您可能希望等到他们完成工作后再加入。有时您情不自禁，但沟通至少可以让您计划复杂的合并，而不是被惊讶。

Answer 2

违反单一职责原则的类是最难合并的。找到一个难以合并的类可能表明它需要重构，可能是在更多部分的方向上。

Answer 3

首先，您的代码库应该是模块化的。其次，您需要的是与团队其他成员的沟通。每个人都应该知道谁在做什么。如果内部 API 发生变化，应该向整个团队说明。

此外，在提交之前，请始终获取最后一个版本，如果需要复杂的合并，请在本地进行。

这真的是人的问题，而不是技术问题。源代码控制不会取代适当的沟通渠道。你的项目经理应该在每一个变化的顶部，他应该意识到什么时候一个变化会涉及到几个人。

此外，需要常识。:)

单元测试当然有助于捕捉合并时可能出现的最难以捉摸的错误。

Answer 4

与您的开发人员交流，并尽可能避免同步编辑同一代码块。拥有良好的模块化架构（小类，解耦功能）几乎可以一直做到这一点。

如果我们确实发生了冲突，我们通常会通过我们中的一个人转而为未经测试的代码编写单元测试几分钟来解决它。