马蜂窝的前端火了！遇到冲突不怕怼，强制提交就是干_前端_weixin

「前言」

相信大家都在世界杯期间有意无意地看到过马蜂窝的洗脑广告，短短的15秒，品牌名就出现了6次。“旅游之前，为什么要先上马蜂窝”，这些不断重复的广告词让人犹如魔咒般印象深刻。

有不了解的小伙伴可以上他们家的官网大概看下，马蜂窝，一家从事旅游行业的新锐互联网公司。

背景铺垫完毕之后，让我们进入今天的正题。

「正文」

最近马蜂窝移动端的某个线上页面出现了明显的BUG，截图在某技术社区疯传，献上页面截图供大家瞻仰一下：

前端圈里的潜规则就是，好事不出门，好玩事儿传千里。瞬间马蜂窝的前端在码农圈子里火了，爱凑热闹的程序猿们纷纷留言：

马蜂窝的前端老哥666，能跑起来也是牛逼
遇到冲突不怕怼，强制提交就是干！！！
请问贵公司还缺前端吗？我就喜欢这样自由任性的开发氛围～
人生不如意之事十之八九，合并分支往往也不是一帆风顺的
我写的代码不会有问题！报错根本不影响页面功能！ie 用户根本不用管！玛德，被开除了…
这要是搁我司，还不得被技术经理diss，一口盐汽水喷死我都是极有可能的！
领导的脑袋嗡嗡嗡...
......

其实仔细想想，发生在马蜂窝身上的这种bug在我们开发环境中很常见，并不稀奇。只要是在前端团队里呆过的码农都知道，这不就是提交代码合并分支发现冲突了，然而并没有解决就直接发布了么。

首先要想清楚一个问题，在类似马蜂窝的前端团队中，为什么git提交代码会出现冲突？

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

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

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

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

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

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

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

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

「 git解决代码提交冲突」

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

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

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

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

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

git rm A.C
 
git rm origin-name.C
 
git add B.C
 
git commit
复制代码

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

git rm B.C
 
git rm origin-name.C
 
git add A.C
 
git commit
复制代码

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

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

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

git rebase remote -branch-name
复制代码

冲突解决的一般步骤

merge/patch的冲突解决

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

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

rebase的冲突解决

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

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

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

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

git rebase --continue
复制代码

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

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

git rebase --skip
复制代码

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

git rebase --abort
复制代码

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

直接编辑冲突文件：

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

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

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

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

总结一下：

当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。

解决冲突就是把Git合并失败的文件手动编辑为我们希望的内容，再提交。

用git log --graph命令可以看到分支合并图。

「前端协作流程」

下面来说说我对前端协作流程的一点理解。

项目的可维护性第一。我们并不是一个人在做事，项目的维护和二次开发可能是直接或间接的团队合作。好的可维护性可以从四个方面获得:

代码的松藕合，高度模块化，将页面内的元素视为一个个模块，相互独立，尽量避免耦合过高的代码，从HTML，CSS，JavaScript三个层面考虑模块化。

良好的注释。

注意代码的弹性，在性能和弹性的选择上，一般情况下以弹性为优先考虑条件，在保证弹性的基础上，适当优化性能。

严格按照规范编写代码。

「如何避免提交冲突」

很多童鞋都把git当作个人代码备份工具，没有涉及多人提交代码到中央版本库。但是在多人使用时，不能简单地再延续原来个人使用时的习惯。如何提交才能避免版本冲突呢？

首先在本地 clone 项目源码回来之后，只有一个默认分支master，不要直接在上面工作。

a.建立一个自己的分支，如取名working： git branch working

b.切换到这个新分支： git checkout working

c.现在可以自由修改代码并保存了。

2.确保你修改的代码都是自己负责项目下，或者说你的两次提交之间，没有其他人来改相同项目下的代码，如果不能避免，你就要在下面的merge步骤手工处理冲突了。

3.提交代码时按下面的步骤：(可以将下面的脚本保存在你的每个项目之下，每次只修改提交一个项目)

git checkout working    --force  #确保使用的是工作分支<br>
git add .<br>
git commit -m"$1" -a     #提交代码到本地，工作分支增加一个版本，这里的$1是运行脚本的第一个参数
 
git checkout master      <br>
git pull origin master   #切换回默认分支，并将默认分支和中央最新版本合并<br>
git merge working        #在本地合并你的这次修改到默认分支<br>
git push origin master   #提交到中央版本库，接下来还是要切换回工作分支的<br>
git checkout working   --force&emsp;
复制代码

如果不小心动了生产环境（就是只从中央版本库pull到本地）的文件，只好将本地版本退回一个，再从中央代码库pull代码合并。