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