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

「 前言 」

相信你们都在世界杯期间有意无心地看到过马蜂窝的洗脑广告，短短的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代码合并。

git reset --hard HEAD

因此说，在平时的前端开发工做中，养成一个良好的有规范的git提交代码的习惯，是多么的重要

「 结尾 」

不过，这个bug事故在发生以后，被马蜂窝的前端人员迅速解决掉了，可见其对bug复现的处理能力，同时对马蜂窝制定测试流程规范的测试工程师致敬！

若是能让我对马蜂窝的前端er说一句话，我只想问一句：

贵公司还缺测试吗？

---

更多文章我会第一时间更新在公众号<闰土大叔>里面，欢迎关注~