当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的

当两条分支对同一个文件的同一个文本块进行了不同的修改，并试图合并时，Git不能自动合并的，称之为冲突(conflict)。解决冲突需要人工处理。

 

那么让我来带领大家解读下上面截图中马蜂窝出现的bug事故分析：

 

<<<<<<<标记冲突开始，后面跟的是当前分支中的内容。

HEAD指向当前分支末梢的提交。

=======之后，>>>>>>>之前是要merge过来的另一条分支上的代码。

>>>>>>>之后的dev是该分支的名字。

对于简单的合并，手工编辑，然后去掉这些标记，最后像往常的提交一样先add再commit即可。

 

这其中就涉及到了公司前端团队协作开发的流程问题，以及git解决代码冲突的实际问题，让我们以马蜂窝的bug事故为引子，来继续深入聊聊团队协作的那些事儿。

 

 

「 git解决代码提交冲突 」

 

现在大部分一线互联网公司都是采用git作为公司内部版本迭代的工具，它可以敏捷高效地处理任何或小或大的项目，自然在前端团队日常协作开发的过程，出现代码提交冲突就很常见了，这也是很多刚入行的前端新人小白们在工作中经常会碰到的比较棘手的问题。

 

代码提交冲突一般分为两种，树冲突和内容冲突。

 

文件名修改造成的冲突，称为树冲突。

 

比如，A同事把文件改名为A.C，B同事把同一个文件改名为B.C，那么B同事将这两个commit合并时，会产生冲突。

 

如果最终确定用B同事的文件名，那么解决办法如下：

1git rm A.C
2
3git rm origin-name.C
4
5git add B.C
6
7git commit

如果最终确定用A同事的文件名，那么解决办法如下：

1git rm B.C
2
3git rm origin-name.C
4
5git add A.C
6
7git commit

 

内容冲突（git pull拉取最新代码发现）

 

一般来讲，出现冲突时都会有“conflict”字样，特别的直接报错repo sync的报错，可能并不是直接提示冲突。

 

现在，需要进入报错的项目（git库）目录，然后执行git rebase解决：

1git rebase remote -branch-name

冲突解决的一般步骤

1merge/patch的冲突解决

先编辑冲突，然后git commit提交。

对于git来讲，编辑冲突跟平时的修改代码没什么差异。修改完成后，都是要把修改添加到缓存，然后commit。

1rebase的冲突解决

rebase的冲突解决过程，就是解决每个应用补丁冲突的过程。

解决完一个补丁应用的冲突后，执行下面命令标记冲突已解决（也就是把修改内容加入缓存）

1git add -u      // -u 表示把所有已track的文件的新的修改加入缓存，但不加入新的文件

然后执行下面命令继续rebase：

1git rebase --continue

有冲突继续解决，重复这这些步骤，直到rebase完成。

如果中间遇到某个补丁不需要应用，可以用下面命令忽略：

1git rebase --skip

如果想回到rebase执行之前的状态，可以执行：

1git rebase --abort

注：rebase之后，不需要执行commit，也不存在新的修改需要提交，都是git自动完成。

 

直接编辑冲突文件：

冲突标记<<<<<<< （7个<）与=======之间的内容是我的修改

=======与>>>>>>>之间的内容是别人的修改

 

最简单的编辑冲突的办法，就是直接编辑冲突了的文件（test.txt），把冲突标记删掉，把冲突解决正确。

 

此时，还没有任何其它垃圾文件产生。