产品开发中的一种Git分支工作方法

新钛云服已累计为您分享689篇技术干货

一、前言

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、一般项目开发

工作流程如上图：

1、项目负责人从master的基线check out，初始化dev分支；

2、开发者从dev分支check out，建立本地个人开发分支feature*；

3、开发者完成功能开发后，commit个人feature*分支，并push至远程个人feature*分支；

4、开发者在gitlab上提交个人的代码和并请求至dev分支；

4、代码审查人负责代码审查，合并合理代码；

6、代码提测时，开发负责人提交dev分支到test的合并请求；

7、项目负责人合并dev分支至test分支；

8、版本测试完成后，开发负责人提交test分支至master分支的合并请求；

9、项目负责人合并代码至master；

10、项目负责人以当前代码为基线，在master分支上tag当前版本号。

3、hostfix版本开发

hostfix为紧急修复的版本，不同于正常需求的版本流程。工作流程如下图。

4、定制化版本开发

定制化版本出现在给某些特定用户提供特殊定制的功能，而又与主干分支存在不同业务逻辑的情况下。工作流程如下图。

5、多版本并行

版本测试的时候，可能存在开发团队眼巴巴等待测试反馈bug的时候。配合默契的多版本并行开发，可以合理利用时间，加速版本迭代。工作流程如下图。

    推荐阅读   

    推荐视频