# gitflow-practice

**Repository Path**: wavewei/gitflow-practice

## Basic Information

- **Project Name**: gitflow-practice
- **Description**: gitflow流程练习
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: develop
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2022-05-25
- **Last Updated**: 2026-01-16

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

## GitFlow项目具有如下分支

```
master branch: 不可push, 拥有所有已发版的稳定功能, 可直接部署到生产. 该分支只有在发布成品的时候运行. develop branch : 开发中心分支, 不可直接push, 拥有最全最新的功能, 不稳定.
feature branches: 每个新特性都在独立的feature branch上进行开发，并在开发结束后merge回develop，分支命名规范：feature/功能说明，比如feature/web_ui
release branches: 为每次发布成品准备的release candidate(候选者), 可理解为预发版分支，在这个分支上只进行bug fix，并在完成后merge回master和develop. 分支命名规范：release/版本号, 例如release/1.0.0
hotfix branches: 用于快速修复，在修复完成后merge回master和develop，分支命名规范：hotfix/issue说明
tag: 用于标记一个制品的正式发布，即release功能完成之后, 合并到master之后, 打发布的版本号tag, 自动构建工具开始制作成品.命名规范：版本号, 例如1.0.0
```

## 工作流程：

### 场景1：添加新功能

```
1. 拉取develop分支代码到本地
2. 创建新功能分支，如：feature/login
3. 基于新分支（feature/login）发开，完成后提交到远程仓库
4. 提交前先commit改动内容到本地仓库，然后拉取（pull）develop分支最新代码，如冲突则本地解决后重新commit，此时会发现很多改动非本人调整，属正常情况，确认核对文件后重新commit后再push到server
5. 创建pr（pull request）到develop分支
6. leader负责合并pr请求，至此新功能开发完成
```

### 场景2： 新功能发布

```
1. 基于develop分支创建release分支（预发布分支,release/1.0.0）
2. QA 测试团队基于release分支进行功能测试，测试通过关闭issue，失败则提交bug case
3. bug修复，基于release分支修复
4. 测试通过后
	4.1 release分支无bug修复，则直接将release分支合并到master即可
	4.2 release分支有bug修复，将release分支合并到master和develop分支
5. 基于master打tag标签(1.0.0)并删除release分支
6. 制品制作
```

### 场景3：hotfix

hotfix分支是因为以发布的制品中发现新缺陷，从而进行紧急对应而产生的分支结构。

```
1. 基于master的tag拉去hotfix分支
2. 基于hotfix分支修复现场bug，提交hotfix分支到远程server
3. 测试通过后将hotfix分支分别合并到master和develop分支，删除hotfix分支
4. 基于master分支打tag标签，如之前版本1.0.0，新tag版本则为1.0.1
5. 制品制作
```

### 场景2流程模拟
```
1. 修复功能1发现的bug
```

### 场景3流程模拟

```
1. 基于tag 1.0.0 拉取新分支hotfix/1.0.0
2. 在分支hotfix/1.0.0中修改bug
3. QA基于hotfix/1.0.0测试
4. 测试通过将hotfix/1.0.0先合并到master然后在合并到develop
5. 删除hotfix/1.0.0
6. 基于master创建新tag1.0.1
```

### 场景4多功能并行开发模拟

```
1. 功能1 提交且进入测试阶段
3. 功能1 bug修复先合并到master然后在合并到develop
2. 功能2 开发完成合并到develop，此时功能1未测试完成且出现bug
```

### 场景5多功能并行开发模拟

```
1. a同学添加功能
```

### 场景5多功能并行开发模拟

```
1. b同学添加功能完成
```