产品开发中的一种Git分支工作方法
新钛云服已累计为您分享689篇技术干货
一、前言
二、产品的软件版本号定义
| 版本号 | 说明 | 备注 |
|---|---|---|
| 主版本号 | 系统业务重构或架构重构时增加；重大功能或方向改变时增加；大范围不兼容之前的接口时增加。 | |
| 子版本号 | 增加新的业务功能时增加。 | |
| 修订号 | 有改动就增加。 | 从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、一般项目开发
4、定制化版本开发
5、多版本并行
推荐阅读
推荐视频
微信扫码关注该文公众号作者
戳这里提交新闻线索和高质量文章给我们。
来源: qq
点击查看作者最近其他文章