# Git分支管理规范

------

本人在实际工作中总结出的Git使用规范，比较简单，容易落地。

## 1. 分支管理

开发过程主要存在以下分支：

- **master**
- **dev**
- hotfix-[问题名称 | bug编号]
- feature-[功能名称]
- bugfix-[bug编号]
- refactor-[重构名称]

### 1.1 master 主分支

```
- master主分支始终保持稳定的可发布版本
- 只有项目组主程才拥有master主分支的管理权限（例如其他分支合并到master必须由主程操作）
12
```

### 1.2 dev 开发分支

```
- dev开发分支为不稳定版本，可能存在功能缺失，但已有的功能必须是完整的
- 原则上不允许直接在dev分支上进行功能开发，必须新建feature分支进行开发
12
```

### 1.3 hotfix-[问题名称 | bug编号] 紧急热修复分支

```
- 从master分支创建，横线后面跟上问题名称或者对应的bug编号，仅仅适用于**生产线问题紧急修复**！！！！
- 修复完成，测试通过，合并到master和dev分支上，然后将此分支删除
12
```

### 1.4 feature-[功能名称] 功能开发分支

```
- 从dev分支创建，横线后跟功能名称，用于新功能开发，每天下班前push提交到远程
- 开发完成以后，在远程发起向dev分支的合并请求，由指定的CodeReview人员审查通过以后进行合并，并删除该分支
12
```

### 1.5 bugfix-[bug编号] 问题修复分支

```
- 从dev分支创建，用于修改测试提出的bug，横线后跟bug编号
- 修复以后，在远程发起向dev分支的合并请求，并指定提交者自身（或其他人）作为CodeReview，合并以后删除该分支
12
```

### 1.6 refactor-[重构名称] 重构分支

```
- 从dev分支创建，用于代码的**重大规模重构**（小规模重构创建feature分支即可）
- 重构以后，必须经过严格测试通过，才能向dev分支合并。
12
```

------

## 2. Commit 提交规范

### 2.1 commit提交的日志格式

【**类型:描述**】，其中类型如下表所示

| 类型     | 描述                         |
| -------- | ---------------------------- |
| feat     | feature，即新开发的功能      |
| fix      | 问题修复                     |
| refactor | 重构代码                     |
| doc      | 增加文档（如readme），注释等 |

例如：

```text
fix:修复身份证含字母X的用户无法注册问题
fix: 紧急修复生产线用户积分不显示的问题
feat:商品详情页功能
doc:增加项目readme文档，修改结算条款结算逻辑的注释1234
```

### 2.2 Commit提交频率

1. 每天下班前必须提交feature分支，并push到远程
2. hotfix、feature、bugfix、refactor分支尽量按照功能点或修复重构的问题及时commit（不要求push）

![](H:\开发环境部署\Git\Git使用规范.png)