第1步:基准分支:母版
/* file: master.txt */
line 1
line 2
line 3
步骤2。签出新分支b1 git checkout -b b1
并按如下所示编辑master.txt
,然后提交。
/* file: master.txt */
line 1 changed
line 2
line 3
步骤3.检出主git checkout master
并检出新分支b2 git checkout -b b2
并按如下所示编辑master.txt
,然后提交。
/* file: master.txt */
line 1
line 2 changed
line 3
第4步。再次结帐母版git checkout master
并合并b1 git 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
我想这是两个开发人员几乎同时签出自己的分支,编辑同一文件,然后一个接一个地合并回基线的常见情况。什么是一种预防从一开始就发生而不是在事后解决冲突的实用方法?感谢您的所有建议。
答案 0 :(得分:2)
如果要防止这种情况发生,则需要使用基于文件悲观锁定的源代码控制工具。这种工具不适用于分布式或大型团队开发,并且会不断干扰中小型团队的工作流程。这就是为什么坦率地说它们不再受欢迎的原因。
还应注意,您的示例可能会误导您。对同一文件的更改将合并而不会冲突,除非它们都编辑了代码的同一部分(“大块”)。当然,如果变更触及同一条线,则它们会重叠(并冲突);但是如果它们碰到相邻的线,它们也会发生冲突。
这就是说,实践中的冲突在大多数项目中并不常见,通常也就不难解决。对于大多数项目而言,解决偶发冲突的成本要比等待另一个开发人员完成其工作并解锁所需文件的成本要低得多。
也就是说,您可以根据需要搜索悲观的锁定源控制工具。尽管在这一点上获得了压倒性的共识,但也许您还是不相信,或者您的项目确实与众不同。
但是在某种程度上,您的问题可以归结为“什么是执行此操作的好工具”,因此对于SO而言这是不合时宜的,所以我不打算讨论。