如何用 git 做项目分支策略和版本发布管理

朱雀 2021-03-29 11:13 682阅读 0赞

在做项目的时候，不管是多人协作，还是单兵作战，都需要用版本管理工具对项目进行管理。市面上的版本管理工具很多，比如有我们比较熟悉的 svn 和 git。它们的优缺点，我们这边不做讨论，大家可以网上搜索。本文主要讨论 git 的一个显著优点：版本的分支管理。下面介绍的是一种实践中证明运行比较良好的版本分支管理方式。

### 主分支

在实际开发中，一个项目的仓库主要有两个主分支：`master` 与 `develop` 分支。这个两个分支伴随着整个项目周期。且不允许直接 push 到这两个分支上。

- `master`：创建 git 仓库时自动生成的原始分支。
  这个分支代表项目处于可发布的状态。其他无关代码不得随便往 master 上合并。只有计划发布的版本功能在 develop 分支上全部完成，而且测试通过后才会合并到 master 上。
- `develop`：基于 master 分支创建，与 master 分支平行，为开发的整合分支。
  主要来源为各程序员的开发功能分支的合并（`Feature branches`，下面会讲到）。

### 功能分支

除了上面的主分支外，我们在开发中还会用到其他功能分支，以帮助团队成员之间进行并行开发，简化功能跟踪，为生产发布做准备并协助快速解决生产中的实际问题。与主分支不同，这些分支的生命周期总是有限的，因为它们被合并后就会被删除。

- `Feature branches`：功能分支。程序员在开发每个功能的时候都需要在各自的功能分支上开发。
  **每次开发新功能都必须从 develop 分支创建，开发完成合并回到 develop 分支后删除**。分支命名可以是除 master、develop、release-*、hotfix-* 外的任何内容，建议使用 feature-*（如 feature-register，代表用户注册的开发分支）。
- `Release branches`：预发布分支。在 master 要发布正式版本之前（即合并到 master 分支之前），我们可能需要有一个预发布的版本进行测试。
  测试过程中如有小调整（比如调整位置、宽度，修改文案等不会引入新 bug），直接在该分支上修改。如果出现大 bug 必须通过创建 feature 分支，走正常流程。如果是一些无关紧要的小 bug，可以推迟到下个版本更新修复。
  **预发布分支是基于 develop 分支创建，预发布结束以后，如有修改必须合并到 develop 和 master 分支。最后删除该分支**。分支命名使用 release-*（如 release-0.1，即 release-预发布版本号）。正式发布时，一般会基于 master 分支创建一个 tag，命名为 tag-*（如 tag-0.1，即 tag-线上版本号）
- `Hotfix branches`：线上 bug 修复分支。项目发布上线后，出现的 bug，在这个分支上修复。
  **该分支基于线上版本对应的 master 分支（或 tag）创建，修复完 bug，必须合并到 develop 和 master 分支。最后删除该分支**。分支命名使用 fixbug-*（如 fixbug-0.1，即 fixbug-线上版本号）。

### 总结图

![](/images/20210329/1617016359617.jpg)