如何防止合并冲突（或至少减少冲突）

动图

几个月前，我写了一篇关于解决合并提交的 DEV 文章。我从读者那里得到的强烈反馈是：“尽量避免这种情况。” 虽然我同意这种观点，但我写这篇文章是为了那些已经过了预防阶段的技术人员。

合并冲突几乎不可避免。在您的职业生涯中，您可能会遇到不止一次合并冲突，但只要沟通良好、规划周密，就能减少合并冲突的发生。让我们来探讨一下如何做到这一点！

了解合并冲突发生的原因

我在之前的 DEV 帖子中提到过这一点，但我认为值得重复一遍。

像 Git 这样的版本控制系统可以自动管理代码贡献。它可以识别变更、发生时间、执行者以及具体行号，以便开发人员轻松追踪其代码库的历史记录。然而，Git 有时会在以下情况下出现问题：

• 当多个人修改文件中的同一行并尝试将更改合并到同一个分支时
• 当一个开发人员删除一个文件，但另一个开发人员编辑该文件时，他们都尝试将他们的更改合并到同一个分支。
• 当一个开发人员删除一行，而另一个开发人员编辑该行，并且他们都尝试将他们的更改合并到同一个分支时
• 当开发人员挑选提交时，即从分支中挑选提交并将其应用到另一个分支的行为
• 当开发人员重新定位一个分支时，即将一系列提交移动到一个基本提交的过程

Git 不确定应该应用哪个更改，因此它会向开发人员寻求帮助，并通知他们合并冲突。您的工作是帮助 Git 确定哪个提议的更改最准确且最新。

防止合并冲突的好处

有时，为了避免合并冲突，为团队或您自己提前做好这些工作可能看起来很繁琐，但这是值得的。使用防护栏来防止合并冲突可以节省时间并提高开发人员的满意度。解决错误、编写新功能或编写自动化脚本都非常耗时。增加调试和解决合并冲突的障碍意味着合并到“主”分支和部署到生产环境的时间都会更长。此外，如果您的团队不断遇到冲突，他们最终会对自己的工作感到失望。

避免合并冲突的四种方法

标准化格式规则

很多时候，冲突是由于格式差异引起的。例如，一位技术人员无意中在另一位开发人员添加新代码的同一行添加了多余的空格。此外，每个人的编码风格也各不相同。例如，有些 JavaScript 开发人员使用分号，而有些则不使用。如果您在团队中工作，请强制执行代码格式化程序和 linting 规则。确保团队中的每个人都了解这些规则和工具，以减少因格式问题而遇到的合并冲突。

进行小规模提交并频繁审查拉取请求

我得承认一件非常尴尬的事。以前（大约三年前），我提交的拉取请求会修改 50 多个文件，然后我会因为太多的合并冲突而恼火。事后看来，我错了。在不到两周的时间内修改 50 多个文件，增加了其他开发人员也更新这些文件的可能性。

此外，创建大型的拉取请求也阻碍了我的队友全面快速地审查我的代码。我的拉取请求会因为过于庞大而搁置，队友们都不想看到它。

吸取我的教训，做一些小的修改，提交它们，并在提交后尽快让其他人审核拉取请求。这样，你修改其他队友正在同时处理的文件的机会就会减少。

变基、变基、变基（尽早且经常）

（我犹豫着写下这些，准备听听评论区会不会反对。显然，我不想要和平；我想要的是永远的麻烦。我有点夸张，而且引用了一个梗。见下文：）

2019年，我从一位同事那里学到了变基（rebasing），我的团队把他称为“Git-tator”（Git 和 dictator 的结合体）。他非常热衷于改进我们初创公司的 git 历史记录，并减少由于合并冲突而导致的阻塞。由于许多开发人员经常同时开发大量的功能，因此经常会发生争吵。我们甚至会因为一些简单的冲突而争吵，比如有人在同一个文件的同一行中为不同的功能导入新的依赖项。于是，他向我们介绍了变基，这极大地改善了我们的软件开发工作流程。

什么是变基？

git rebase 命令会将一个分支的更改重新应用到另一个分支，这与 git merge 命令非常相似。不过，git rebase 会重写提交历史记录，从而生成连续的、线性的提交。

变基如何帮助防止合并冲突

变基并不能神奇地消除所有合并冲突。事实上，在变基过程中，您可能会遇到冲突。有时，您需要在变基过程中反复解决同一个冲突。然而，合并冲突的发生是因为同一代码块同时发生了多项更改。如果您将本地工作分支变基到默认分支（主分支或 master 分支），则您将使用默认分支的历史记录重写本地提交历史记录，然后重新应用更改。在许多情况下，先变基再合并可以简化团队合作。变基是一种选择，但不是唯一的解决方案。

谨慎使用 rebase

请注意——有时不建议使用变基操作。变基操作很危险，因为您正在重写历史记录。进行变基操作时，请注意您正在接受的更改，因为这可能会覆盖团队成员的更改，或包含团队成员原本想要删除的文件。您也可能不想在主分支上对公共仓库进行变基操作，因为这会错误地重写历史记录。

如果您对 rebasing 还不熟悉或者对 rebasing 感到紧张，请与队友一起进行健全性检查。

我如何通过 rebase 来避免合并冲突

没有绝对正确的工作流程，只有自己喜欢的工作流程。以下是我根据自己工作过的团队和代码库总结出的工作流程：

• 如果我和多人合作，我会从默认分支创建一个功能分支。这样，我们就可以一起为该功能分支做出贡献。
• 我将从默认分支或功能分支创建一个新的本地分支
• 我将添加并提交新的更改到我的本地分支
• 我将从默认或功能分支重新制定更新
• 我将把本地分支的更改合并到默认分支或功能分支

关注并沟通

任何 git 命令或软件工具都无法取代工程团队的沟通需求。成为一名优秀的软件开发人员和协作者，不仅仅需要编写代码。优秀的软件开发人员会与团队成员沟通。让你的团队了解你将要接触的文件，并与你的产品经理和 SCRUM Master 协调，避免开发与其他功能冲突的功能。

如果你独自工作，可以假装自己在团队中工作：

• 创建分支
• 创建拉取请求
• 避免拉取请求变得过时
• 在合并之前的更改之前，请确保没有更改相同的代码行
• 建立并遵循格式规则

独自工作不应该妨碍你养成良好的编码习惯，所以尽量保持代码库的整洁！你的代码库可能会变成一个开源项目，或者成为你在面试中炫耀的项目。

如果您正在阅读本文并且正在考虑“我只是需要帮助解决冲突”，请转到此帖子。

请注意：我没有用尽所有防止合并冲突的选项，因此请在下面评论您用来避免合并冲突的方法。

另外，请关注GitHub和我的DEV 以获取更多精彩内容。

请继续关注我正在撰写的一篇文章，其中介绍了合并提交、压缩和变基之间的区别。

动图