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

Question

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

有没有人有制作低冲突变化的策略？这是不是TDD或其他方法的东西（当然TDD会帮助抓住它们，但它实际上是否会阻止它）？

Answer 1

我总是发现我的提交越小，合并冲突的可能性就越小。那些遇到大问题的人似乎总是在几天内完成工作，然后尝试将它们全部合并。

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

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

另外，与您的团队交谈。如果你知道其他人在某个特定文件中工作，你可能要等到他们开始工作之后才开始工作。有时你无法帮助它，但沟通至少让你计划复杂的合并而不是吃惊。

Answer 2

违反single responsiblity principle的类是最难合并的。找到一个难以合并的类可能是一个需要重构的标志，可能是在更多部分的方向上。

Answer 3

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

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

这实际上是一个人为问题，而不是技术问题。源控制不会取代正确的通信渠道。您的项目经理应该掌握每一项变更，他应该意识到变更将跨越多个人。

此外，还需要常识。 ：）

单元测试当然是一个很大的帮助，可以捕捉合并时可能出现的最难以捉摸的错误。

Answer 4

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

如果我们确实发生了冲突，我们通常会在几分钟内切换到针对未经测试的代码编写单元测试来解决这个问题。