版本末期，海量需求汇入主分支。由于平时都是单独的功能开发分支，虽然一直跟着主分支的更新，而同步更新。但是团队在开发截止日最后两天，大家都不断往上合并自己的需求点。这时候解决冲突就成了老大难。
可恨的冲突
说到git冲突问题，有一肚子苦水。要承认git是非常优秀的版本管理工具，但是再优秀的工具也有让人诟病的地方。而冲突合并就是最大问题。经常遇到的场景如下：你在主开发分支develop下运行了get merge feature/version-yourdev(你自己的开发分支)，并且十二万分的精神，仔细解决其中冲突。完成后你开心的发布，且很有自豪感，心想又一个完美需求要上线了。但是帅不过三秒，公司内部群开始反馈，说那里出问题了。然后相关同事说自己已经修复了，并发出灵魂拷问谁刚刚动过代码。这时候你傻眼了。赶紧一顿操作，要重新解决冲突。而且可能还不一定对。但是要我说，你还要暗自庆幸，毕竟不是线上。否者，直接原地爆炸。
merge的合并规则
学会解决冲突前，要明白merge的合并规则。merge是采用三方合并的规则完成的。也就是说，假设develop为base，再此基础上创建develop-a和develop-b两个分支，这时候develop的header commitId称为O, develop-a的header commitId称为A,develop-b的header commitId称为B。然后A commit 中我们修改1.js中的96行代码。这用merge的合并规则来说，会用O和B下的1.js中的96行代码与A比较。因为O/B相同认为A被修改，此处保留A的修改。注意：此时，如果B下的1.js也被修改了。那这时候就会提示冲突，然后人工修改。
如何解决冲突
知道了冲突的由来，解决他的思路也就有了。
- 从根本上解决冲突的产生，业务按模块划分。这样的好处在于，同一文件下，往往只有一个人会去修改。
- 如果已经产生冲突，那么这里有三条小技巧。
- 使用vscode插件，这里推荐使用GitLens-Git supercharged。该插件被1千6百多万次的下载，还能拥有4.5星的好评。可以说是vscode生态下最好用的git插件。
- sourcetree软件，他的好处是可视化的commit提交记录，以及冲突信息。也是我电脑必备软件之一。
- GitLab仓库地址。使用它merge require 或者合并review简直不要太爽。也良心推荐。
结束语
git工具，说简单很简单，因为上手非常容易。说难也难，因为真正把他玩透还是需要一些时间和精力的。但是作为开发过程中，必不可少的工具之一。还是建议大家能够重视。也希望文本能帮大家避坑（冲突从此说再见）。
今天的疲惫，来源于昨天的松懈。
