时间戳

首页 > 解决方案 > 合并回源分支时两个分支冲突

git - 合并回源分支时两个分支冲突

问题描述

Step 1. 基线分支：master

/* file: master.txt */
line 1
line 2
line 3

步骤 2. 签出新分支 b1git checkout -b b1并master.txt进行如下编辑，然后提交。

/* file: master.txt */
line 1 changed
line 2
line 3

步骤 3. 签出 mastergit checkout master和 checkout new branch b2git checkout -b b2并编辑master.txt如下，然后提交。

/* file: master.txt */
line 1
line 2 changed
line 3

步骤 4. 再次结帐 mastergit checkout master并合并 b1git merge b1

步骤 5. 留在 master 分支并尝试合并 b2 git merge b2，有冲突

/* file: master.txt */
<<<<<<< HEAD
line 1 changed
line 2
line 3 
=======
line 1
line 2 changed
line 3
>>>>>>> b2

我想两个开发人员几乎同时检出他们自己的分支，编辑同一个文件，然后一个接一个地合并回基线是很常见的。首先防止这种情况发生而不是事后解决冲突的实用方法是什么？感谢您的所有建议。

标签： gitmerge-conflict-resolution

解决方案

如果要防止这种情况发生，则需要使用基于文件悲观锁定的源代码控制工具。这样的工具不适用于分布式或大型团队开发，并且会不断干扰中小型团队的工作流程。这就是为什么坦率地说它们不再受欢迎的原因。

还应该注意的是，您的示例可能会误导您。对同一文件的更改将合并而不会发生冲突，除非它们都编辑代码的同一部分（“hunk”）。当然，如果它们触及同一条线，则更改会重叠（和冲突）；但如果它们接触相邻的线，它们也会发生冲突。

也就是说，实践中的冲突在大多数项目中并不常见，而且通常也不难解决。对于大多数项目来说，解决偶尔冲突的成本要比等待其他开发人员完成他们正在做的事情并解锁您需要的文件的成本要低得多。

也就是说，如果需要，您可以搜索悲观锁定源代码控制工具。尽管在这一点上达成了压倒性的共识，但您可能并不相信，或者您的项目可能确实有所不同。

但是在某种程度上，您的问题归结为“什么是执行此操作的好工具”，这对于 SO 来说是题外话，所以我不会讨论这个问题。

推荐阅读