一、前言
Git作为版本控制管理工具中的优秀代表，其分支管理功能使得团队协同开发成为一件非常简单的事情。本文介绍一种产品开发中的Git分支工作方法，以供探讨。
二、产品的软件版本号定义
软件版本号定义，分四项：主版本号.子版本号.修订号.Build号，如：V1.3.2.123软件hotfix版本号定义，分四项：主版本号.子版本号.修订号.修补号，如：V1.3.2.125
版本号 | 说明 | 备注 |
主版本号 | 系统业务重构或架构重构时增加；重大功能或方向改变时增加；大范围不兼容之前的接口时增加。 | |
子版本号 | 增加新的业务功能时增加。 | |
修订号 | 有改动就增加。 | 从0开始 |
修补号 | hostfix版本号基于所修复的版本的Build号，取发布版本的最大的Build号往上增加如果修复基于V1.3.2.1，则hotfix版本为V1.3.2.2如果当前发布版本的Build版本是V1.3.2.101，当前最大Build号为105，则修补版本号为V1.3.2.106 | 从1开始 |
Build号 | 编译号，有编译就增加。 | 从1开始 |
三、Git分支命名
1.基本分支
分支命名 | 说明 | 生命周期 |
master | 记录上线版本的迭代，该分支代码与线上代码是完全一致的主分支 | 项目存在期间存续，项目下线之后归档 |
dev | 记录开发代码活动历史 | 同master |
test | 记录测试活动历史 | 同master |
feature-(ver)-(name) | 属于开发个人的代码活动历史记录，如David正在开发1.0.1版本，则分支名为：feature-v1.0.1-david | 版本开始开发至版本发布，版本发布后结束 |
2.扩展分支
分支命名 | 说明 | 生命周期 |
hostfix-(ver) | 线上版本的紧急修复代码分支，开发与测试都采用同一分支 | 版本开始开发至版本发布 |
dev-(company) | 记录针对特定需求的定制化版本的开发代码活动历史 | 项目存在期间存续，项目下线之后归档 |
test-(company) | 记录针对特定需求的定制化版本的测试代码活动历史 | 同dev-(company) |
feature-(company)-v1.0.2-(name) | 属于开发个人的定制化版本的开发代码活动历史记录，如David正在开发的定制化阿里公司的1.0.1版本，则分支名为：feature-ali-v1.0.1-david | 版本开始开发至版本发布，版本发布后结束 |
dev-v1.0.2 | 多分支并发开发时，记录特定版本的开发代码活动历史 | 版本开始开发至版本发布 |
test-v1.0.2 | 多分支并发开发时，记录特定版本的测试代码活动历史 | 版本开始开发至版本发布 |
3、tags
tag命名 | 说明 | 生命周期 |
tag-v(ver) | 仅针对发布版本打tag，如：tag-v1.0.0.1 | 项目存在期间存续，项目下线之后归档 |
四、Git分支工作规范
1.分支工作基本原则
master：系统版本的准线，版本通过测试并处于可发布状态时，才可合并入master，一直维持可构建状态。
dev*：协同开发分支，不可直接提交，仅可通过其他分支合并进入。
test*：测试分支，不可直接提交，仅可通过dev*分支合并进入。
feature*：个人开发分支，个人开发完成需要合并入dev分之前，先push至远程feature分支。
2.一般项目开发
工作流程如上图：
- 项目负责人从master的基线check out，初始化dev分支；
- 开发者从dev分支check out，建立本地个人开发分支feature*；
- 开发者完成功能开发后，commit个人feature*分支，并push至远程个人feature*分支；
- 开发者在gitlab上提交个人的代码和并请求至dev分支；
- 代码审查人负责代码审查，合并合理代码；
- 代码提测时，开发负责人提交dev分支到test的合并请求；
- 项目负责人合并dev分支至test分支；
- 版本测试完成后，开发负责人提交test分支至master分支的合并请求；
- 项目负责人合并代码至master；
- 项目负责人以当前代码为基线，在master分支上tag当前版本号。
3.hostfix版本开发
hostfix为紧急修复的版本，不同于正常需求的版本流程。工作流程如下图。
4.定制化版本开发
定制化版本出现在给某些特定用户提供特殊定制的功能，而又与主干分支存在不同业务逻辑的情况下。工作流程如下图。
5.多版本并行
版本测试的时候，可能存在开发团队眼巴巴等待测试反馈bug的时候。配合默契的多版本并行开发，可以合理利用时间，加速版本迭代。工作流程如下图。
