概要

在git使用中，尤其是多人维护相同项目时，“冲突”是一个经常要解决的问题，但是对这个问题似乎一直似懂非懂。现在感觉真的想明白了，这里把它从发生到处理整个机制做个描述。

一、“冲突”是如何发生的？

有人会说“当多个人同时改一个文件时会发生冲突”，这句话不能说错，但其实很不精确。个人觉得更精确的说法应该是“当多个人从同一个主分支，各自拉出相同的子分支后，又在各自的子分支中改了同一个文件时，冲突会在第一个人合并回主分支后，其他人再合回主分支时发生在那个相同的文件上”。

二、“冲突”场景举例

        假设有一个项目A，由甲乙两个程序员共同维护，里面一共有a、b、c三个文件。程序员甲首先接到一个需求，需求会改动到文件a和b，于是他从项目A的主分支拉出了开发子分支A1，按部就班开始了工作。正在这时，有人发现项目A在线上出现一个bug需要马上处理，于是程序员乙接受了任务并发现修复bug要修改文件b，在又从项目A中拉出了他的子分支A2后，也按部就班开始了工作。

        程序员甲和程序员乙拉了各自的分支A1和A2后，双方开始写代码前，A1和A2是和A完全相同的两个副本，有着相同的a,b,c三个文件。然后甲乙各自开始工作后，他们都修改了文件b，这个文件便会在后期引发冲突。如果乙先处理完bug，并将自己的分支合并回主分支，他不会遇到任何问题，但是后一步完成需求合并回主分支的甲却会遭遇发生在文件b上的冲突。如果相反，是甲先完成需求与合并，乙后处理完bug与合并，那么就是乙在文件b上遭遇冲突。

        这里不难发现，在多人维护相同项目时，单个项目开发周期越长，将来它合并回主分支遇到冲突的概率就越高，因为跟你拉出相同的分支的可能有多个人，你如果在最后才提交合并，要处理的冲突可能也涉及多个人，你要面对一对多的沟通协调，虽然冲突的处理不当可能对自己和别人都有影响，但是所有的锅肯定都是最后处理冲突的人，所以项目切记不要拖太久。

三、git为什么要设计“冲突”机制

        因为没有冲突机制，多个人改相同文件时，后合并的人就会覆盖先合并的人的改动，在最终效果上就是先合并的人的工作在主分支上被归零，就像他没合并过一样。如果在处理冲突时，直接“以己方分支为主”的方式处理，也是会覆盖先合并之人的工作。

四、“冲突”的解决

        在发生冲突的文件里，一般都会被插入一些"特殊的字符"，类似"<<<<<<< HEAD"、“=======”、“>>>>>>> feature1”这些，它们是帮助你看清冲突的位置，告诉你相同的地方，你和对方有什么不同：比如文件b第12行，对方的版本是空行，但你却有一句代码。如果你看出冲突是什么了，就可以删除"<<<<<<< HEAD"、“=======”、“>>>>>>> feature1”这些符号了。然后接下来你就要处理问题，比如你可以很确定，自己在12行增加的代码对对方的代码毫无影响，那就可以自己的为主。

这里要强调的是，只在这一行以自己为主，而不是整个文件为主，很多时候，一个文件可能有多处冲突，每个冲突你都要切实深入细节确定双方的影响。对于改动较大的情况，多数时候只是遭遇冲突的人单方面是无法判断影响的，他只知道以自己的为主自己没问题，不确定是否影响对方，这时就要通过git的log找到上一个合并者，两个人一起看冲突发生的地方，确认一个两个人都不会影响的修改方案。

链接: https://fly63.com/article/detial/7031