git - 如何最小化 git 合并冲突？

Question

我们公司使用 git 来跟踪文档/代码更改，有几个人进行更改并推送到中央存储库。一般来说，他们中的大多数都是 git 或命令行工具的新手。对于他们，我们有脚本可以在进行更改后更新或发布他们的本地仓库。

是否有任何工作流程更适合此类情况，以最大程度地减少发生的合并冲突，这些冲突必须由更有 git 经验的人来解决？

score 6 · Accepted Answer

合并冲突的第一个原因是每次合并之间的时间。
您在每次合并之间等待的时间越长，您就越能确定合并冲突。

您可以通过选择合并工作流程（例如git flow）来最小化这种情况，该工作流程将提倡每个功能的分支，并促进任务的隔离。
但是只要涉及到一组共同的文件（在两种不同的开发中），你最终会出现合并冲突，尤其是如果你等待的时间太长。

因此，对于分布式VCS，学习定期发布（推/拉），并在合并之前学习 rebase。

这不仅会减少冲突的数量，还会减少语义冲突的数量：这些合并似乎是自动的（没有冲突），但会产生不正确的代码。
请参阅“更好、更简单的‘语义冲突’示例？ ”。

score 6 · Accepted Answer

Git 不能替代正确的开发实践。它不会为您编写更好的代码。

如果两个开发人员接触完全相同的代码，git 无法让他们的工作更轻松，如果是合并冲突，无论你是否在分支上，它都会是一个。

短期解决方案：使用适当的本地和远程分支来封装不同功能的工作。使用分支差异（或 github 拉取请求）来审查功能集并帮助解决差异和冲突。

长期：修复您的代码，使您的代码适应您的团队，反之亦然，并使用适当的开发实践。

score 2 · Accepted Answer

没什么神奇的。主要是纪律。

如果人们必须执行诸如拉取请求之类的操作，或者在与某些“主”存储库或分支合并之前等待审查提交，请尽量缩短审查时间。

您可能应该尝试缩短分支的生命周期，但这实际上取决于您正在从事的项目类型。

规定所有提交必须尽可能小。制定一条规则，即提交必须只改变一件事。规定不要将外观更改（如空格）与功能更改和重大重构混为一谈。（不要完全禁止空白更改 - 只需将它们与其他更改分开即可。）

除了版本控制本身之外，尝试以一种减少他们在同一周左右更改相同代码的机会的方式将任务分配给编码人员。

score -1 · Accepted Answer

这里有一篇文章可以帮助你更好地理解，“一个成功的 Git 分支模型”。它指出您应该区分不同类型的分支，其中包括：

4 回答 4