Git分支管理规约就像红绿信号灯为道路上的行人、司机提供通行指导一样，为版本快速迭代、稳定部署提供了操作指导。

对于持续发布的项目，核心原则是上游优先（upstream first）：只有上游分支采纳的代码变化，才能应用到下游分支。适用于独立应用开发。

一、环境分支

环境分支即长期分支，为了保障项目迭代、发布的稳定可靠，这些分支需要限制进行 push 操作，仅可通过提交 pull request 并进行 code review 完成变更合并。

对于持续发布项目，通常有开发环境、预发环境、生产环境三类基础环境的配置，其与 Git 分支的对应关系如下：

二、迭代分支

迭代分支即开发分支，是一种短期分支，每开启一次项目迭代就需要基于master分支创建与迭代对应的新分支进行开发提交。具有以下管理规约：

1、迭代分支命名 sprint/xxx ，其中“xxx”为项目管理工具中的迭代号

2、迭代分支由项目迭代的负责人（master）本地创建，完成基本的前置调整后推送至远程团队共享仓库。操作过程如下：

（1）更新本地master分支保持与远程master分支同步（重点注意：本地如果超前于远程master，说明本地分支存在污染，需要检查清理）

（2）基于本地master分支切出迭代分支，例如：sprint/20230310，其中“20230310”是对应的迭代号

（3）基于本地sprint/20230310分支完成前置调整，并提交commit后，推送并创建对应的远程sprint/20230310分支。前置调整内容示例：

a）追加本次迭代的内容于 changelog.md

## 迭代<迭代号>

### 迭代周期：yyyy/MM/dd 至 yyyy/MM/dd

- 发布 版号
- 新增
  - 功能1
  - 功能2
- 变更
  - 变更1
  - 变更2
- 修复
  - 修复1
  - 修复2

b）完成项目工程的相关基础工作，如：分模块、分包、数据建模、基础工具等

（4）基于远程迭代分支向远程master分支发起pull request（此PR称为迭代PR），持续至迭代完成。此PR的发起信息要求：

a）标题信息要求：#<迭代号>:内容描述

b）描述信息要求：本次迭代需求条目

3、迭代提交commit信息格式要求：安装 Git Commit Template 插件

（1）Header区域：（必填）

a）Type of change 提交类型，常用的是 feat 功能开发、fix 修复缺陷

b）Scope of this change 影响范围，一般为改动的模块名。如：客户端鉴权模块、用户登录模块

c）Short description 改动概述，如：客户端鉴权领域模型重构、用户登录模式扩展

（2）Body区域：（必填）Long description 改动内容，可分条目多行，例如：

（1） 客户端领域模型新增授权方式识别控制

（2）客户端领域模型新增权限集合属性

（3）Footer区域：（非必填）

a）Breaking changes 不兼容变动，通常在移除废弃接口的提交中需要填写

b）Closed issues 关闭问题，通常在解决用户反馈的缺陷问题修复时需要填写其链接

（4）revert 类型提交说明

特殊情况【回滚，Revert】：如果当前 commit 用于撤销以前的 commit，
（1）必须以revert:开头，后面跟着被撤销 Commit 的 Header。
（2）Body部分的格式是固定的，必须写成 This reverts commit <hash>.，其中的hash是被撤销 commit 的 SHA 标识符。

4、迭代周期内，代码本地提交后，可直接推送到对应的远程迭代分支。为保证迭代效率、避免代码冲突，做如下约定：

（1）每日工作开始需拉取远程迭代分支进行本地更新

（2）每日工作结束需推送本地提交至远程迭代分支

（3）一次远程推送的提交必须确保程序完整可运行（否则将导致次日团队成员拉取更新后出现无法运行的事故）

（4）每日对迭代PR进行Code Review，并完成所有意见反馈的处理

5、待迭代发布上线后，迭代分支可删除（在这之前必须保留）

三、修复分支

持续迭代模型中不存在紧急修复，所有反馈的BUG原则上需要在最近的迭代分支中完成修复。但为了解决生产环境出现严重功能问题急需修复的特殊场景，新增了违背“上游优先”原则的修复分支用于适应特殊场景需要。修复分支具有以下管理要求：

（1）修复分支命名 hotfix/xxx，其中“xxx”描述为修复功能

（2）单个修复分支仅限修复单个功能问题（存在多个功能问题急需修复时，需要通过多个修复分支进行处理）

（3）修复分支基于production分支切出，修复完成后需要并入production分支，优先进行生产环境修复

（4）修复发布稳定后，需要将修复更改并入master分支以及pre-production分支

（5）修复分支发布稳定后，并且完成修复更改并入后，分支可删除

四、持续发布模型示例图