> For the complete documentation index, see [llms.txt](https://yangsx95.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yangsx95.gitbook.io/notes/version-control/git/git-fen-zhi-guan-li.md).

# Git分支管理

## 2022年4月28日（公司4）

### 1. Git分支类型功能定义

1. UAT，预发布分支，用户发布UAT环境，产品验收
2. FAT，测试分支，用于测试人员验收测试
3. DEV，开发分支/集成分支，始终保持最新完成以及bug修复的代码，对应发布环境dev
4. feature分支，功能分支，用于管理迭代需求使用。为了减少后续合并麻烦，一般基于版本分支创建，或者开发过程中做rebase操作
5. hotfix分支，用于处理生产环境紧急bug之用。以TAG为基线，创建hotfix分支，修复完成后，需要合并到UAT分支、DEV分支、FAT分支
6. TAG，tag为标签，用于标记提测或发布版本，Tag代码不能进行直接修改。Tag一般在测试PRE准出后生成

### 2. 分支命名规范

| 分支类型  | 命名格式                   | 举例                    |
| ----- | ---------------------- | --------------------- |
| 预发布分支 | uat                    |                       |
| 测试分支  | fat                    |                       |
| 开发分支  | dev                    |                       |
| 需求分支  | feature/{feature-name} | feature/jira需求编号      |
| 补丁分支  | hotfix/{服务版本}-{当前日期}   | hotfix/1.0.1-20220101 |
| 标签分支  | tag/{服务版本}-{当前日期}      | tag/1.0.1-20220101    |

### 3. 分支协作规范

#### 一、常规迭代开发步骤

1. 新的迭代开始时，开发人员以线上tag切出`feature/{feature-name}`开发功能分支。
2. 开发人员在`feature/{feature-name}`功能分支开发/修改新的迭代功能。
3. `feature/{feature-name}`开发完毕后，开发人员 merge 到dev分支，并使用jenkins发布到dev环境，然后自测。自测通过后进入第4步，如果需要修改进入第2步。
4. `feature/{feature-name}`功能分支merge到fat分支，测试人员jenkins发版fat环境，测试人员验证功能。如果验证成功进入第5步，否则开发人员修改问题进入第2步。
5. `feature/{feature-name}`功能分支merge到uat分支，产品验收迭代功能。如果验证成功进入第6步，否则开发人员修改问题进入第2步。
6. 产品验收通过后，开发以uat分支打一个tag，tag的名称可以为：`tag/{服务版本}-{准出日期}`

注意：

1. 多个迭代可以同时开发
2. 不同版本的需求产品不能同时验证
3. 同一个发布版本里的产品可以同时验证

#### 二、线上紧急问题修复步骤如下

1. 开发人员以线上Tag切出hotfix分支，分支名称为`hotfix/{服务版本}-{上线日期}`
2. 开发人员在hotfix分支上修改问题
3. 开发人员修改完毕后，将需要测试的修改内容cherry-pick到dev分支，研发人员自测。验证成功进入第4步，否则进入第2步。
4. 开发人员自测完毕后，将需要测试的修改内容cherry-pick到fat分支，测试人员验证问题。验证成功进入第5步，否则进入第2步。
5. 测试人员测试完毕后，将需要测试的修改内容cherry-pick到uat分支，产品验证问题。验证成功进入第6步，否则进入第2步。
6. 最后根据hotfix分支创建tag生产分支，进行发布。

### 4. 版本号定义

版本号体现在pom的version定义中，以`1.0.0-SNAPSHOT`，从前往后每个部分分别对应：

1. 主版本号：增加模块或者整体架构发生变化，由产品经理、项目经理共同讨论决定是否修改。
2. 次版本号：增加新功能或本次变动造成程序与之前的版本不兼容，或者是功能上有大的变更。此版本号由项目经理决定更改。
3. 修订版本号：线上Bug修复或者一些功能的扩充。此版本号基于线上bug，由开发经理更新。
4. 阶段版本号：测试环境为SNAPSHOT版本，生产环境对应RELEASE版本。

备注，软件版本的阶段：

* Base版: 此版本表示该软件仅仅是一个假页面链接，通常包括所有的功能和页面布局，但是页面中的功能都没有做完整的实现，只是做为整体网站的一个基础架构。
* Alpha版: 此版本表示该软件在此阶段主要是以实现软件功能为主，通常只在软件开发者内部交流，一般而言，该版本软件的Bug较多，需要继续修改。
* Beta版: 该版本相对于α版已有了很大的改进，消除了严重的错误，但还是存在着一些缺陷，需要经过多次测试来进一步消除，此版本主要的修改对像是软件的UI。
* RC版: （Release   Candidate）该版本已经相当成熟了，基本上不存在导致错误的BUG，与即将发行的正式版相差无几。
* Release版: 该版本意味“最终版本”，在前面版本的一系列测试版之后，终归会有一个正式版本，是最终交付用户使用的一个版本。该版本有时也称为标准版。一般情况下，Release不会以单词形式出现在软件封面上，取而代之的是符号(Ｒ)。

### 5. 分支与环境的对应关系

```
分支   环境
dev -> dev
fat -> fat
uat -> uat
tag/不同版本tag -> pro
```

备注，各种环境总结：

1. pro（Production environment）：生产环境，面向外部用户的环境，正式环境，连接上互联网即可访问。
2. sit(System Integration Test ): 系统集成测试，开发人员自己测试流程是否走通。
3. uat(User Acceptance Test environment): 用户验收测试环境，用于生产环境下的软件测试者测试使用。
4. test: 测试环境，外部用户无法访问，专门给测试人员使用的，版本相对稳定。
5. pre ：灰度环境，外部用户可以访问，但是服务器配置相对低，其它和生产一样，外部用户可以访问，版本发布初期，正式版本发布前。
6. dev （Development environment） ： 开发环境，外部用户无法访问，开发人员使用，版本变动很大。
7. fat (Feature Acceptance Test environment) : 功能验收测试环境，用于软件测试者测试使用