---
title: Git 分支管理流程规范
keywords: teedoc, gitflow, git, 静态博客
desc: Git 分支管理流程规范
author: devin
date: 2023-05-20
tags: blog, blog, teedoc
---





## **Git** **分支与GitFlow 流程的规范**

**1、**   **GitFlow** **原理介绍**

Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。

![图示  描述已自动生成](file:///C:/Users/11047158/AppData/Local/Temp/msohtmlclip1/01/clip_image002.png)

工作流中涉及到的角色介绍：

- 功能开发者：模块中功能的开发人员；
- 开发管理员：由项目模块开发的小组长（team leader）担当；
- 测试管理员：由测试团队指定人员担当；
- 发布管理员：由生产环境发布团队指定人员担当；

### 分支说明

| ![img](file:///C:/Users/11047158/AppData/Local/Temp/msohtmlclip1/01/clip_image004.jpg) |      |      |      |      |      |
| ------------------------------------------------------------ | ---- | ---- | ---- | ---- | ---- |
|                                                              |      |      |      |      |      |

 

**2、**   **Git** **分支**

### 2.1 Master/Develop 分支

所有在 Master 分支上的 Commit 应该打上 Tag，一般情况下 Master 不存在 Commit，Develop 分支基于 Master 分支创建。

![图片包含 图示  描述已自动生成](file:///C:/Users/11047158/AppData/Local/Temp/msohtmlclip1/01/clip_image006.png)

### 2.2 Feature 分支

Feature 分支做完后，必须合并回 Develop 分支, 合并完分支后一般会删点这个 Feature 分支，
 毕竟保留下来意义也不大。

![卡通人物  中度可信度描述已自动生成](file:///C:/Users/11047158/AppData/Local/Temp/msohtmlclip1/01/clip_image008.png)

### 2.3 Release 分支

Release 分支基于 Develop 分支创建，打完 Release 分支之后，我们可以在这个 Release 分支
 上测试，修改 Bug 等。同时，其它开发人员可以基于 Develop 分支新建 Feature (记住：一旦打了
 Release 分支之后不要从 Develop 分支上合并新的改动到 Release 分支)发布 Release 分支时，合并
 Release 到 Master 和 Develop， 同时在 Master 分支上打个 Tag 记住 Release 版本号，然后可以删除 Release 分支了。

![图表, 示意图  描述已自动生成](file:///C:/Users/11047158/AppData/Local/Temp/msohtmlclip1/01/clip_image010.png)

### 2.4 Hotfix 分支

hotfix 分支基于 Master 分支创建，开发完后需要合并回 Master 和 Develop 分支，同时在
 Master 上打一个 tag。

![图表, 示意图  描述已自动生成](file:///C:/Users/11047158/AppData/Local/Temp/msohtmlclip1/01/clip_image012.png)

 

**3、**   **Git** **分支的合并和Commit**

### 3.1 基本要求

- 所有commit必须有注释，**内容必须按照注释格式严格执行！** 
- 合理控制提交内容的颗粒度，一次commit含一个独立功能点。严禁一次提交涵盖多个功能项。
- 正确为每个项目设置Git提交用到的user.name和user.email信息，以公司邮箱为准，不可随意设置以影响无法正确识别。     查看当前项目配置信息的命令：`git config     -l` 

### 3.2 版本

- 版本号(tag)命名规则：`主版本号.次版本号.修订号`，如`2.1.13`。(遵循GitHub[语义化版本](https://links.jianshu.com/go?to=https%3A%2F%2Fsemver.org%2Flang%2Fzh-CN%2F)命名规范)
- 版本号仅标记于master分支，用于标识某个可发布/回滚的版本代码
- 对master标记tag意味着该tag能发布到生产环境
- 对master分支代码的每一次更新(合并)必须标记版本号
- 仅项目管理员有权限对master进行合并和标记版本号


 
 

### 3.3 Commit 规范日志

提交信息一定要认真填写！

- 建议参考规范：<type>(scope)：<subject>
- 比如：fix(首页模块)：修复弹窗 JS Bug。
- type 表示 动作类型，可分为：
- fix：修复 xxx     Bug
- feat：新增     xxx 功能
- test：调试     xxx 功能
- style：变更     xxx 代码格式或注释
- docs：变更     xxx 文档
- refactor：重构 xxx 功能或方法
- scope 表示 影响范围，可分为：模块、类库、方法等。