背景
在项目开发过程中，往往一个优秀的产品都会出现不断的版本迭代，我时常在项目发布后对于如何结合后续更新的业务场景在分支上的应用没有一个很好的办法，一直也比较苦恼。目前项目的迭代场景如下，一个A项目，经过需求分析，产品经理下令开发团队开发，那么经过数月后成功上线，发布V1.0.0.0. 紧接着我们就会进入第二期开发，产品经理会列出第二期的具体开发内容，随即我们就开干了……，然后在开发过程中，发布出去的V1.0.0.0反馈出很多问题，有业务的，有紧急的，各种情况的问题….
对于上面的问题，我相信很多人都遇到过，如果是你，你会怎么做呢？我先说一下目前我的做法，首先我放弃了主分支概念，当产品经理说我们第一个版本为V1.0.0.0时，我在git上就创建出了分支V1.0.0.0,我以版本为分支的形式来应对。当进入第二期时，我会根据V1.0.0.0的最新commit来创建出一个新分支V1.0.0.1作为下一个版本的开发分支。如果V1.0.0.0反馈有问题，我会立即切回到V1.0.0.1分支上进行开发，测试，然后tag一个新的标签出来为V1.0.0.0.1 作为修复版本……，然后将代码合并到V1.0.0.1上继续开发。
对于上面这种玩法前期还好，后期有一个重大缺点，因为按照版本号创建的分支，所以后期分支会非常多，难以维护，最终会把自己累死。
| 优点 | 缺点 |
|---|---|
| 使用 tag 明确版本 | 分支命名不清晰（既是 1.0.0.0 又包含 1.0.0.1 内容） |
| tag 打在某个 commit 上是合理的 | 没有合并到主分支（main），未来不好维护 |
| 便于查看历史提交 | 如果多人协作，容易造成混乱 |
| 能记录版本信息 | 后续修复 bug 不方便追溯 |
标准版本发布流程
后来基于上面的痛点以及询问了一些前辈的意见，打算使用如下的一个流程。这是一个 基于 Git 的常见版本管理流程（适用于敏捷开发）：
1.分支结构
| 分支 | 用途说明 | 是否要长期存在 |
|---|---|---|
| master | 主分支，用于生产环境代码 | 长期 |
| dev | 开发主分支，集成所有功能 | 长期 |
| release/版本号 | 准备发布的版本分支(不加新功能) | 临时 |
| hotfix/版本号 | 紧急修复分支(不加新功能) | 临时 |
2.版本开发 & 发布流程图
develop
↓ merge → release/4.1.0.1 → 测试团队测试
↓
测试通过 → 打 tag v4.1.0.1
↓
merge 到 main（或直接部署）
↓
merge 回 develop（带回 bug 修复）
3.标准流程
3.1 创建release/版本号 分支
先创建出一个分支release/4.1.0.1
3.2 根据产品经理发布的版本进行开发
在dev分支上开发完要求的功能内容
3.3 在release/版本号做最后调整跟测试
开发完成的功能合入
release/4.1.0.1修复一些小问题（不能加新功能）
3.4 提交给测试部门测试
- 将
release/4.1.0.1分支提交给测试部门测试 - 测试完成后确认没问题
3.5 合并到主分支
- 合并到
master上 - 在最新的commit上打上tag=
v4.1.0.1
3.6 合并到开发分支
- 合并到
dev上
3.7 删除release
- 看一下需要，如果不经常再变动，可以先删掉。后期如果需要，可以再根据tag标记的位置根据实际情况来新建出
/release/版本号
4.如果上线后发现 bug 怎么办？——打 Hotfix
4.1 创建 hotfix 分支
先基于某一个tag:v4.1.0.1上新建一个紧急分支出来hotfix/4.1.0.1-patch1
4.2 修复 bug 并测试通过
- 将
hotfix/4.1.0.1-patch1分支提交给测试部门测试 - 测试完成后确认没问题
4.4 合并master
- 合并到
master上 - 在最新的commit上打上tag=
v4.1.0.1-patch1
4.5 合并到开发分支
- 合并到
dev上
4.5 删除分支
- 删除
hotfix/4.1.0.1-patch1分支