操作不规范，同事两行泪

那似乎是一个再寻常不过的早晨，南吃完两个豆腐包，简单地用纸巾擦拭了一下嘴巴，便缓缓打开他高贵的mac笔记本，又是愉快的一天呢~

 

不对！

 

敏锐的嗅觉告诉他，平静之中隐藏着一丝危险的信号~

 

南环顾四周，目光最终锁定在水杯的十点钟方向。“该死，差点被行政扣掉10块钱！”

 

多年来刀光剑影的日子早已练就出一身沉稳，没有半分慌乱，南自然地将工牌从水杯旁取过戴到了脖子上，“哼哼，一切都在掌控之中。”

 

这个版本的业务没有难度，但如何在同事面前装B便成了一个问题…

 

不过话说回来，产品部的赵美人着实漂亮，身材纤细苗条，双眼含藏不漏，令人销魂蚀骨，与古筝小姐姐真是难分伯仲啊，妈蛋，又走神了~

 

十指在键盘上滚动，光标在荧幕上起舞，噼里啪啦的打击声似乎在演奏一曲优雅的最炫名族风。

 

commit -> pull -> merge -> tag -> push

 

行云流水，一气呵成~

 

南翘起二郎腿，身子斜靠在椅子上，拿起东方树叶喝了一口，恐怕只有茉莉花的清香在划过咽喉的瞬间才能带给他一些喜悦罢。

 

没错，提交代码之后做自测，是一名高级程序猿的必备习惯。

 

但是，诡异的一幕出现了，竟然！没~有~结~果！不敢相信！

 

mvn clean install -Dmaven.test.skip=true

 

竟然！还~是~没~有~结~果！

 

南的眉头拧成了一个疙瘩。你没有看错，他认真了，早已不知有多少个年头没有见过他这个样子。

 

依稀记得那是在幼儿园大班的时候，学校曾经举办过一次象棋比赛，由于学生们年纪尚浅，参与者寥寥无几，而他，在仅有的三人中，力战群雄，以季军的结果而告终。

 

南一遍又一遍地回忆着之前的操作，绝对没有纰漏！既然如此，来吧！

 

大威天龙！

大罗法咒！

雕虫小技，竟敢班门弄斧，真是不把我放在眼里！

commit-log，出~

今天就要你原形毕露！

杀！杀！杀！

 

事情是这样的，他们团队在开发过程中，每个版本都要从pro分支checkout -b出一个test分支，再checkout -b出一个功能分支a和一个功能分支b；（也许还有功能分支c，功能分支d等）

>>pro

>>test

>>a

>>b

 

经过开发，不断将a，b两个分支的代码合到test分支上做测试；

>>pro

>>test(a,b)

>>a

>>b

 

正常情况下向pro分支合功能代码，比如说a功能，checkout pro -> merge a，将a功能直接合到pro分支上；

 

但某个同事却搞出了骚操作，虽然结果看起来是相同的，checkout pro -> merge test -> delete b（删除功能b相关的代码）；

 

接着将test分支删除，再从最新的pro分支上拉一个test分支出来，branch -D test -> checkout pro -> checkout -b test；

 

问题就来了，如今的pro分支我们称作pro'，test分支我们称作test'，pro' = test'，两者的版本时间相同，b = pro，也就是说b的版本落后于pro'版本与test'版本；

 

落后的版本差中记录的关于b的操作是什么呢？merge + delete，所以，当checkout test' -> merge b的时候，只有在delete b之后的，对于b的修改才会被merge进来，之前的merge已经被delete掉了；

 

问题定位到，解决自然不是难事，南随后在公司技术群里出了一套Git提交规范，下面是测试的例子：

> mvn clean install -Dmaven.test.skip=true （编译功能分支代码）

> git commit -a -m 'log' （提交功能分支代码）

> git checkout test （切换到test分支）

> git pull origin test （拉取最新的test分支代码）

> git pull origin --tags （拉取最新的标签）

> git merge mine （合并功能分支代码）

> mvn clean install -Dmaven.test.skip=true （编译合并的代码）

> git tag -a 'tag-name' -m 'log' （打标签，这个流程可以保证最新的标签是最新的代码）

> git push origin test （推送代码到远程仓库）

> git push origin --tags （推送标签到远程仓库）

 

又是愉快的一天呢~