解决多分支并行开发公共文件维护的几种方案

发表于 分类于

前言

当项目越来越大，且存在多分支同时开发的时候，就会遇到公共文件维护的问题；比如当在A分支修改某个公共文件时，B分支无法同步该文件的修改，毕竟两个开发分支（迭代）的排期和测试进度是不一样的，不能贸然交叉合并开发分支，否则会造成代码污染的问题。因此需要一种解决方案来专门维护项目公共文件，避免出现公共文件修改不同步造成各种冲突和可能存在的关联性bug出现。

方案一：npm私库

利用npm私库可以把项目公共组件部分独立成npm包，不受分支影响；

优点：

  • 独立性强
  • 可以存在多个版本，有问题时可以快速回滚版本，也可以发版本修复

缺点：

  • 组件调试不方便
  • 文档插件兼容性和引入方式待确认

方案二：git subtree

利用git subtree将公共组件文件夹变成项目的一个子仓库，关于公共组件的修改可以全部同步在子仓库，其他分支可以随时从子仓库pull进行同步；

优点

  • 相对项目内其它文件，子仓库文件比较独立
  • 无需结构更改，可以无缝兼容项目结构
  • 组件调试方便

缺点

  • 子仓库相关更新的subtree命令比较繁琐（不过目测可以通过添加npm script解决）
  • 需要严格遵循子仓库的改动必须使用subtree命令提交

方案三：独立的公共文件维护分支

就是指定一条分支专门维护公共文件（包括公共组件），也就是说所有涉及到公共文件的修改全都必须切到该分支，修改后在该分支进行上传；且该分支不能合并其他任何开发或测试分支的代码，但是可以定期合并主分支代码（已通过测试的）；

优点

  • 利用git分支即可维护项目公共文件，无需额外学习成本
  • 同样兼容已有项目结构
  • 组件调试方便
  • 不仅可以维护组件，还能维护其他公共文件

缺点

  • 需要保证公共文件维护分支的纯洁性，即不能让其他分支污染

优化措施

由于公共文件比较特殊，可以考虑引入一些工具加强规范，减少人为错误，和及时的改动通知等；

  • 公共文件改动群通知：无论是git库，还是单独分支，都可以利用webhook进行钉钉群通知；
  • 规范commit消息，自动生成公共文件changelog：利用一些成熟的工具加强commit消息格式，然后每次自动记录生成规范的changelog文件，以便有清晰的修改记录，而且commit通知也会更具可读性；
  • 针对方案三，可能存在一种强制校验的方式来禁止合并其他代码的分支到公共文件分支：利用git hook来检测本地代码合并是否满足要求，目前也有相关的npm包支持这种git hook，比如：husky。但是由于需要写脚本来验证是否有命令能够支持检测merge来源分支，所以尚不明确；

相关文档