环球新资讯：产品开发中的一种Git分支工作方法
2022-09-21 08:55:21来源：新钛云服
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开始 |
分支命名 | 说明 | 生命周期 |
master | 记录上线版本的迭代，该分支代码与线上代码是完全一致的主分支 | 项目存在期间存续，项目下线之后归档 |
dev | 记录开发代码活动历史 | 同master |
test | 记录测试活动历史 | 同master |
feature-(ver)-(name) | 属于开发个人的代码活动历史记录，如David正在开发1.0.1版本，则分支名为：feature-v1.0.1-david | 版本开始开发至版本发布，版本发布后结束 |
分支命名 | 说明 | 生命周期 |
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 | 项目存在期间存续，项目下线之后归档 |
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的时候。配合默契的多版本并行开发，可以合理利用时间，加速版本迭代。工作流程如下图。
