前言
- 本文源自我本人所在团队Git分支管理的规范指导，不代表任何行业标准
- 本工作流适用于以单元测试为主、无集成测试的项目代码分支管理
原则
- 简洁：尽可能少地创建分支，减少分支管理成本和协同成本
- 快速：保持标签版本随时可发布，通过单元测试及代码检视保持主干的稳定性
分支关系图
主分支：main
- 主分支会不断地自动构建并运行单元测试；
- 主分支是相对稳定的分支，需经过严格的代码检视及单元测试；
- 主分支是受保护的，只有仓库维护者可以将开发分支合并到主分支，合并行为即转测试；
无测试环节的项目代码，需要通过充分的单元测试保证代码质量，因此无开发分支
两大临时分支
特性分支：feature-xxxx
- 特性分支由开发人员基于主分支创建，用於单个功能特性的开发；
- 特性分支应遵守一特性一分支的原则，便于代码检视、需求跟踪、问题分析等活动；
- 特性分支的命名应为
feature-[需求编号]，以便于自动关联需求、需求跟踪； - 特性分支在单元测试通过后，由作者推送到代码仓库，并由作者发起向主分支的合并请求；
- 特性分支的合并，应由仓库维护者进行代码检视后，再合并到开发分支；
问题修复分支：fix-xxxx
- 问题修复分支由开发人员基于开发分支创建，用於单个问题的修复；
- 问题修复分支应遵守一问题一分支的原则，便于代码检视、问题跟踪；
- 问题修复分支的命名应为
fix-[问题单号]，以便于自动关联问题单； - 问题修复分支在单元测试通过后，由作者推送到代码仓库，并由作者发起向主分支的合并请求；
- 问题修复分支的合并，应由仓库维护者进行代码检视后，再合并到主分支；
临时分支合并的补充说明
- 特性分支与问题修复分支推送之间，应先从主分支合并最新代码；
- 合并策略为rebase，即永远将自己的提交放在最后，以保持版本历史记录的清晰；
- 应谨慎地解决冲突，使用可视化工具如IDEA/WebStorm合并代码，有必要时叫上产生冲突者结对合并；
可视化工具的代码合并窗，最左为我方代码，中间为原始代码，右边为第三方代码； 蓝色为新增的代码，灰色为删除的代码，红色为冲突的代码，红色代码需要谨慎处理。
版本的发布
主版本标签：vx.x
- 当主分支的代码经过评估，准备发布时，需要打上版本号标签；
- 主版本标签以
小写字母v+主版本号命名，如v1.0； - 版本标签的目的是为了可追溯、可关联，指定版本的发布以标签代码为准；
版本补丁
补丁分支
- 当发布的版本出现网上问题、需要紧急修复时，需要基于版本标签创建补丁分支；
- 补丁分支以
大写字母V+主版本号命名，如V1.0； - 补丁分支遵循非必要不创建的原则，以减少分支管理的复杂度；
- 补丁分支暂时不创建单独的CI环境、测试环境，未来视情况部署到预发布环境；
补丁版本标签：vx.x.x
- 当生产环境网上问题修复、单元测试、代码检视后，需在版本分支上打上补丁版本标签；
- 补丁版本标签以
小写字母v+补丁版本号命名，如v1.0.1；
为保证版本管理的简洁性，网上问题应尽量在主版本中修改，酌情发布补丁 考虑到网上问题的快速修复要求，暂时不限制补丁版本的代码直接合入 补丁版本的提交，视情况合入主分支