关于Git冲突解决引入问题的思考

最近团队里连续出现几次代码合并问题，结合其他开发组的线上问题总结，代码冲突导致的问题确实是比较常见的一个原因，这个不得不让我们去思考，如何才能杜绝这类低级问题。

我们采用的是 master + develop + feature + hotfix 四类分支开发的方式，特性开发与问题修复很可能改动到相同的文件，工作中 Git 代码冲突比较常见；比如一个开发人员正在做购物车的一个新特性开发，同时线上发现问题或者紧急需求插进来，需快速处理，这个时候就会导致一个文件在不同分支都有改动。

从我们的工作流程上来说，开发+测试都是在特性分支上做，接近测试完成了才将代码合并到主干分支（develop 或者 master）；代码合并导致的问题，一般都发生在特性、修复分支合并到 master 或者 develop 的时候，因为这个时候开始，才是真正与其他分支汇合，不同的改动会发生冲突；而此时开发+测试都会认为功能基本没有问题了，就算测试在集成环境回归一遍，也不会像开发分支上那么仔细的测试，所以合并导致的问题也比较容易带入到线上。

既然合并没法完全避免，我们只能去思考如何减少合并冲突，以及冲突解决的时候如何减少问题；

如何减少合并冲突

更合理的分工

人员职责划分尽量清晰，减少互相之间的交叉，让每个功能点都只有一个人在负责或者只有一个人在主要负责，减少多个人同时改动同一份代码的几率；而如果负责人比较忙，功能需要调配到其他同事开发，在方案制定，code reivew，代码冲突处理方面都需要有原负责人参与。
单线程任务安排

故名思义，就是合理安排项目，减少同一个功能点，出现并行开发项目，而改动相同文件的情况；尤其要避免的是在多人共同开发时，某个人将代码来了一遍格式化的情况，会导致其他人的代码很难合并进来；对于无法避免的并行开发情况，需要在先完成开发的项目在合并到 develop 分支后，及时将 develop 反合并到其他特性开发分支，也就是说特性开发分支要经常从 develop 分支拉取最新的改动；

如何减少冲突处理导致的问题

合适的合并工具

合适的代码合并工具，能提供足够的改动参考信息；我自己经常用的是 tortoisegit 的内置合并工具，能够清晰的显示出冲突双方的改动情况，也能显示出合并后的文件实际情况。
合并后的代码检查

让代码实际运行一遍；如果有自动化测试，那么这个执行起来会比较容易，如果没有，那至少也需要将涉及冲突的解决后的代码实际运行一遍，比如前端代码可以使用打包工具打包一遍，验证是否存在打包问题；在浏览器里面使用 mock 数据运行一遍，看看是否存在低级的语法问题，功能、交互是否正常等；

引入 eslint 工具(比如link-stage + husky)，在 precommit 阶段，强制执行静态代码检查；
找到对的负责人 review

如果冲突的不是自己负责的代码，那就要找到具体的负责人来参与代码合并，让其来做决策并实际运行一遍，看看合并结果是否正常，不要想当然的替他人做决定。
对 Git 操作不够熟悉时要多咨询

不懂的 Git 操作，一定要多 google 或者找其他人咨询。Git 的操作还是有一定复杂度的，错误的操作影响也比较大，之前就发生过有人发现冲突不好解决，就把自己分支的内容给强行 push 上去了，导致 develop 分支部分代码丢失，事后处理时，还很难查到具体出问题的时间点，不好评估具体丢了哪些功能点。
公共代码改动，要通知各使用方变化点。
评估冲突代码的影响面，并通知 QA 注意侧重回归测试。