前端 NPM 多包项目 GIT 规范与发版流程思考

简介

为什么需要讨论一套开发及发版流程：

1. 由于项目为 NPM 多包项目，相比其它前端项目不区分环境，只区分版本及 dist-tag，且每次是所有包一起发布，与目前其它前端项目不同；

2. 目前只有 prod 分支且内部测试版本及latest 版本都在prod 分支发布，缺少一个维护对外 latest 版本代码的分支，无法对 latest 版本进行 hotfix；

3. 若新增 test 分支，开发人员需要合并两次代码（合到 test 及合到 prod），若有冲突也要解决两次，增加开发人员负担，且合并时版本号容易冲突；

4. 最重要的一点是，NPM 项目多版本并行发版需求不大，以敏捷迭代为目标，只需迭代到一段时间比如两周上线一个正式版本供外部人员使用即可，其余版本可只发内部人员使用。

解决方案

首先关于 dist-tag

• 如果发布版本时不指定 dist-tag，NPM会默认将所发版本号打上 latest tag，当用户在首次 npm install xxx 或者 npm install xxx@latest 时会安装该版本

• 其它 tag 的版本则需要指定版本号或者 tag 进行安装，如 dist-tag=next时，需 npm install xxx@1.x.x 或者 npm install xxx@next

• 所以可以 latest tag 生产版本对外，发 next tag 测试版本对内

开发及发版步骤简要说明

1. 长期维护的主干分支有 master、latest、next 分支，master 分支为归档分支，latest 分支为用于发布latest 版本的分支，next 分支为用于发布 next 版本的分支

2. 版本分支由 master 分支切出，对应开发人员再从版本分支切出开发分支进行开发，开发完成后合并回版本分支

3. 当需要发布版本进行测试时，将开发完成的版本分支合并到 next 分支，由发版人员进行打版本号及发布版本，并打上 dist-tag 为 next

4. 若版本测试发现 bug，对应开发分支修复 bug 后，由发版人员再次发布版本，dist-tag 为 next

5. 一个迭代周期后，需要发生产版本时，由发版人员将 next 分支合并到 latest 分支，打上生产版本号并发布版本，打上 dist-tag 为 latest，归档到 master 分支

6. 若生产版本号有紧急 bug需要修复，从 latest 分支切出 hotfix 分支进行修复，并叠加生产版本号，打上 dist-tag 为 latest，归档到 master 分支

分支命名规则

• 版本分支：{版本英文名称+下划线分词}_{版本分支创建时间，格式为YYYYMMDD}；例如：develop_agile_v2_20220510

• 功能分支：feature/{版本英文名称+下划线分词}_{版本分支创建时间，格式为YYYYMMDD}_{功能英文名称+下划线分词}；例如： feature/develop_agile_v2_20220510_variable_sdk

• 热修复分支：hotfix/{热修复英文名称+下划线分词}_{bug 单 id，没有则不加}；例如：hotfix/variable_sdk_1231231231232131

• 发布分支：release/{版本号}，例如release/0.1.4-rc.1

流程图

特点

• 发版可控，next 分支大家都可以合并且让发版人员进行发版并内部使用，latest 分支为当迭代到合适时机由发版人员发生产版本供内外部使用

• 由 next 分支合并到 latest 分支，减轻开发人员心智负担，只需关注内部测试，由发版人员关注生产版本，且能保证生产版本功能不遗漏

• next 分支 、 latest 分支 、master 分支 三个分支循环合并，保持动态一致，一种冲突只会解决一次，不需要担心解决冲突导致的版本差异越来越大的问题

• 适合有规划的发布版本的项目，但是不适合多个并行发版需求并且时间不确定的项目

Reference