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

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

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

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

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

如何减少合并冲突

  1. 更合理的分工

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

  2. 单线程任务安排

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

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

  1. 合适的合并工具

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

  2. 合并后的代码检查

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

    引入eslint工具(比如link-stage + husky),在precommit阶段,强制执行静态代码检查;

  3. 找到对的负责人review

    如果冲突的不是自己负责的代码,那就要找到具体的负责人来参与代码合并,让其来做决策并实际运行一遍,看看合并结果是否正常,不要想当然的替他人做决定。

  4. 对Git操作不够熟悉时要多咨询

    不懂的Git操作,一定要多google或者找其他人咨询。Git的操作还是有一定复杂度的,错误的操作影响也比较大,之前就发生过有人发现冲突不好解决,就把自己分支的内容给强行push上去了,导致develop分支部分代码丢失,事后处理时,还很难查到具体出问题的时间点,不好评估具体丢了哪些功能点。

  5. 公共代码改动,要通知各使用方变化点。

  6. 评估冲突代码的影响面,并通知QA注意侧重回归测试。