前言
经过产品不断的折磨，终于形成成熟的分支管理规范。在此分享给大家。
按照项目开发流程，假定由 xiaoHong 和其他 X 位同事负责 1.1.0 版本的研发工作，每个阶段分支管理如下：
阶段一 ： 开发周期
- 主开发分支：从 develop 分支创建 feature/1.1.0 分支（若没有 develop 分支则从 master 分支创建）。
- 模块开发分支：从主分支 feature/1.1.0 创建自己的模块开发分支 feature/1.1.0-kyc。模块开发完成后合并到主开发分支 feature/1.1.0。
- 个人开发分支：从模块开发分支 feature/1.1.0-kyc 创建自己的开发的分支 feature/1.1.0-kyc-xiaoHong。开发完成后合并到模块开发分支 feature/1.1.0-kyc。
备注：如果是多模块开发，需要单独建立模块分支，减少代码耦合。方便按需上线单独模块。
阶段二 ： 测试周期
- 主开发分支：将 feature/1.1.0 合并到 develop 分支， 然后从 develop 分支创建 release/1.1.0 分支。
- 个人开发分支：从 release/1.1.0 创建自己的开发分支 release/1.1.0-xiaoHong。开发完成后合并到主开发分支。
阶段三 ： 版本发布
- 从 release/1.1.0 发布版本，发布后将 release/1.1.0 分支合并到 master 和 develop 分支，并在 master 分支打 1.1.0 的 tag。
阶段四 ： 线上紧急修复
- 主开发分支：从 1.1.0 的 tag 创建主开发分支 hotfix/1.1.0 分支。
- 个人开发分支：从 hotfix/1.1.0 分支创建 hotfix/1.1.0-xiaoHong 个人开发分支，开发完成后合并到主开发分支。
- 使用 hotfix/1.1.0 分支发布紧急修复版本，发布后合并到 master 分支，并打 tag。
总结
- 每位开发要基于个人分支开发，不可使用主开发分支
- 常用分支类型与意义：
master ： 每次发布版本
develop ： 开发分支
feature/x.x.x : 开发周期主分支
release/x.x.x : 测试周期主分支
hotfix/x.x.x : 紧急修复主分支
- commit log 要写完整的变更内容，根据类型添加前缀
功能变更：feat：xxx
Bug修复：fix：xxx
功能优化：opt：xxx
- 版本发布后要及时合并代码到 master 分支，并打 tag
- 及时清理不再使用的分支
意义
- 清晰的分支树，方便版本管理
- 模块间减少耦合，可单独上线完成开发的模块
- 历史版本和修改追溯
