Git：分支管理_release分支

本文目录

1 使用方法

1.1 常规开发

1.2 热修复

1.3 净化Test分支

2 冲突解决

3 分支说明

3.1 master分支

3.2 release分支

3.3 test分支

3.4 feature分支

3.5 hotfix分支

---

结合个人工作经验，对代码分支管理有一些见解，通过博文记录一下，欢迎各位博友指导。

整体分支管理如图所示：

1 使用方法

1.1 常规开发

步骤：

(1) 基于release分支，创建【feature_<需求编号>/<需求内容>】分支，并在该feature分支上进行开发；

 - 若需要依赖某个未上线的feature分支内容，可基于相应feature分支创建；

(2) 开发完成后，将feature分支合并至test分支，将test分支部署到测试环境，进行测试；

(3) 测试通过后，将feature分支合并至release分支，将release分支部署到生产环境，删除feature分支；

(4) 部署生产环境后，若未出现问题，将release分支合并至master分支；

- 若出现问题，参考【1.2 热修复】步骤。

注意：

(1) 非正式代码（例如：为了调试，临时增加的日志打印代码），应在test分支上提交，不应在feature提交，避免污染release分支；

(2) 当存在跨版本的feature分支时，应在适当时机将最新稳定版release分支合并至当前feature分支，避免feature分支内容过于陈旧，累积冲突；

1.2 热修复

步骤：

(1) 基于release分支，创建【hotfix_<YYYYMMDD>/<修复内容>】分支，并在该hotfix分支上进行本地开发；

(2) 开发完成后，将hotfix分支合并至test分支，将test分支部署到测试环境，进行测试；

(3) 测试通过后，将hotfix分支合并至release分支，将release分支部署到生产环境，删除hotfix分支；

(4) 部署生产环境后，若未出现问题，将release分支合并至master分支；

- 若出现问题，重复【1.2 热修复】步骤，直至问题修复。

注意：

(1) 非正式代码（例如：为了调试，临时增加的日志打印代码），应在test分支上提交，不应在hotfix提交，避免污染release分支；

1.3 净化Test分支

步骤：

(1) 根据实际情况，在适当时机，删除现有test分支，并基于最新release分支创建新的test分支；

(2) 目前正在开发中的feature和hotfix分支，重新合并至test分支，将test分支部署至测试环境；

意义：

测试环境的意义是为了模拟线上环境，尽早发现代码问题，避免问题代码被部署到线上环境，导致线上发生异常。

若test分支长期不进行净化操作，将累积很多非正式代码内容及无效提交记录，最终将出现test分支与release分支代码不一致的情况，测试环境模拟线上环境的功能受到影响。

2 冲突解决

在分支管理过程中，需要重点注意冲突的解决方式，避免出现分支内容混合及代码覆盖问题，此处，单独说明几点需要注意的事项。

(1) release → master：理论上不应该出现冲突；

(2) feature/hotfix → test：出现冲突时，在本地，拉取最新test分支，将feature/hotfix合并至test分支，在test分支解决冲突后，提交test分支代码；

(3) feature/hotfix → release：出现冲突时，在本地，拉取最新release分支，将release合并至feature/hotfix分支，在feature/hotfix分支解决冲突后，提交feature/hotfix分支代码；

(4) release → feature（跨版本情况）：出现冲突时，在本地，拉取最新release分支，将release合并至feature分支，在feature分支解决冲突后，再继续开发；

简记：关于test冲突在test解决，关于release冲突在feature/hotfix解决；

切记：不要在GitLab页面上解决分支冲突问题。

3 分支说明

3.1 master分支

- 分支权限：不可提交（no commit），可合并（merge）；

- 基准分支：可作为commit数量变化对比的基准分支；

- 标签分支：每个新发稳定版的打标签在master分支；

3.2 release分支

- 分支权限：不可提交（no commit），可合并（merge）；

- 发布分支：用于发版线上环境的分支；

- 分支规范：

(1) 仅通过测试的正式代码（包括feature和hotfix），才可合并至release分支；

(2) 当发现线上Bug时，由release分支创建hotfix分支进行修复，hotfix分支先合并至test分支测试，通过后，再合并至release分支；

(3) 当release分支发版线上环境并稳定运行一段时间后（具体时机视情况而定），将release分支合并至master分支并在master分支上打新版标签（归档）；

(4) 每次归档新版代码后，删除现有test分支，由最新release分支创建新的test分支（净化test分支），将最新release分支合并至当前正在开发中的跨版本feature分支；（此步骤可根据团队开发情况选择适当时机）

(5) 当feature/hotfix分支合并至release分支发生冲突时，应先在本地将origin/release分支合并至本地相应feature/hotfix分支，并在本地解决冲突后，再合并至release分支；

3.3 test分支

- 分支权限：可提交（commit）、可合并（merge）；

- 测试分支：用于部署测试环境，进行代码测试；

- 分支规范：

(1) 非正式代码（临时的测试/调试/试验代码），应在test分支上进行提交并尝试运行，不要在feature分支上提交非正式代码，例如：临时输出部分日志代码、试错代码等；

(2) test分支不会合并至任何其它分支，仅用于当前阶段代码测试，每当有新稳定版代码归档，删除现有test分支，重新由release分支创建新的test分支（净化test分支）；

(3) 当feature/hotfix分支合并至test分支发生冲突时，应在本地的test分支解决冲突，避免test分支内容混入feature/hotfix分支；

3.4 feature分支

- 分支权限：可提交（commit）、不应有合并（merge）；

- 开发分支：作为需求开发分支，每个feature分支负责一个相对独立的需求，尽可能降低不同feature分支之间的冲突范围（改动的重叠范围）；

- 分支规范：

(1) 每个feature分支应基于release分支创建（最新已发版代码），但若需要依赖某个未上线的feature分支内容，可基于相应feature分支创建；

(2) feature分支开发完成后，应先合并至test分支测试，通过后，再合并至release分支；

(3) feature分支仅提交正式代码，以确保最终合并至release分支的内容都是正式有效的内容；（避免release和master出现非正式代码提交记录：test、asdasd、1等脏数据提交）

(4) 当存在跨版本的feature分支时，应在适当时机将最新稳定版release分支合并至当前feature分支，在本地的feature分支解决冲突，避免冲突积累；（切记不可直接在GitLab上解决冲突）

3.5 hotfix分支

- 分支权限：可提交（commit）、不应有合并（merge）；

- 热修分支：作为热修复分支，及时修复线上问题并发版，每个hotfix分支应只负责修复一个线上问题，当存在多个问题时，应创建多个hotfix分支，不要在同一个hotfix上修复不同问题；

- 分支规范：

(1) 当hotfix分支修复代码完成后，必须先经过测试环境检测，通过后，才可以合并至release分支发布；

(2) 一般情况下，hotfix分支不会出现合并冲突问题；