> ## Content Index
> Fetch the complete content index at: https://lucent.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Git工作流指南：GitFlow工作流
- URL: https://lucent.blog/gitflowgong-zuo-liu/
- Published: 2020-11-30T03:56:04.000Z
- Updated: 2026-08-21T00:49:56.000Z
- Author: Lucent

# 准备工作

在一切开始前，需要先配置SSH Key才能正常拉取或提交代码，方法如下：

1. 在Git Bash或cmd中执行命令

```ssh
ssh-keygen -t rsa -b 2048 -C "你的邮箱"

```

将上面文件中的内容复制到如下图所示的输入框即可  

![企业微信截图_16067012812030.png](https://img-1251540275.cos.ap-shanghai.myqcloud.com/blog/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_16067012812030_1606701299659.png)

执行完成后会在你选择的路径下生成文件（id\_rsa.pub即是你需要的）  

![企业微信截图_16067009893653.png](https://img-1251540275.cos.ap-shanghai.myqcloud.com/blog/%E4%BC%81%E4%B8%9A%E5%BE%AE%E4%BF%A1%E6%88%AA%E5%9B%BE_16067009893653_1606701020733.png)

# 工作流程

Git有许多工作流可供选择，其中包括：Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。  
但请记住：这些流程仅应被视作为指导方针，而非“铁律”。因此，如果有必要的话，你可以组合使用不同的流程。

相对于传统的单分支或功能分支，Gitflow工作流定义了一个围绕项目发布的严格分支模型。

## 工作方式

Gitflow工作流仍然用中央仓库作为所有开发者的交互中心。和其它的工作流一样，开发者在本地工作并push分支到要中央仓库中。

**下面将逐个说明Gitflow工作流中的各个分支**

### 历史分支

相对于单分支模式使用单一的master分支来记录历史，Gitflow工作流使用两个分支来记录历史（即master和develop）  
**master分支存储了正式发布的历史** 
**develop分支存储了功能开发的历史**  

![gitworkflowreleasecycle1historical.png](https://img-1251540275.cos.ap-shanghai.myqcloud.com/blog/git-workflow-release-cycle-1historical_1606702080947.png)

### 功能分支

每一个新功能都使用一个功能分支进行开发，这个功能分支应该从develop分支检出，而非master分支，**master分支只保存生产环境代码**。

```ssh
git checkout -b feature-test develop ##从develop分支检出新的功能分支

```

![gitworkflowreleasecycle2feature.png](https://img-1251540275.cos.ap-shanghai.myqcloud.com/blog/git-workflow-release-cycle-2feature_1606702759836.png)

在此分支功能开发中：

```ssh
# 查看本地代码状态
git status
# 拉取更新
git pull
# 提交代码到本地仓库
git add . ##'.'代表提交所有变化的文件，当然也可以指定文件
git commit -m '修改了***'
# 提交代码到中央仓库
git push

```

当功能开发完成后，需要将代码提交至develop分支，**不能直接提交回master分支**。

```ssh
# 拉取更新
git pull origin develop
# 切换到develop分支
git checkout develop
# 合并分支
git merge --no-ff feature-test
# 推送到中央仓库
git push
# 开发完成并合并成功后这个功能分支可以删除了
git branch -d feature-test

```

### 发布分支

当有功能需要发布的时候，可以从develop分支fork一个发布分支。这个分支用于开始发布循环，从这个时间点起，发布分支不再增加功能，只进行bug修复、文档和其他工作。当发布工作完成时，发布分支合并到master并打好tag。**当然，从创建发布分支到发布完成所作的修改也要合并回develop分支。**

```ssh
# 从develop分支检出发布分支
git checkout -b release-v0.1 develop
# 推送分支到远程仓库
git push

```

当功能bug修复并发布完成，合并发布分支到master

```ssh
# 切换到maste分支
git checkout master
# 将发布分支与当前分支合并
git merge --on-off release-v0.1
# 将合并后的内容推送到远程仓库
git push

```

由于发布分支对代码进行了bug修复，还需要将这些更改合并回develop分支

```ssh
# 切换到develop分支
git checkout develop
# 将发布分支与当前分支合并
git merge --on-off release-v0.1
# 将合并后的内容推送到远程仓库
git push
# 此时，这个发布分支可以删除了
git branch -d release-v0.1

```

发布分支是作为功能开发（develop分支）和对外发布（master分支）间的缓冲。**只要有合并到master分支，就应该打好Tag以方便跟踪。**

```ssh
# 创建Tag
git tag -a v0.1 -m 'release v0.1' master
# 推送Tag到远程仓库
git push --tags

```

### 维护分支

维护分支或说是热修复（hotfix）分支用于生成快速给产品发布版本（production releases）打补丁，这是唯一可以直接从master分支fork出来的分支。修复完成，修改应该马上合并回master分支和develop分支，master分支应该用新的版本号打好Tag。  

![gitworkflowreleasecycle4maintenance.png](https://img-1251540275.cos.ap-shanghai.myqcloud.com/blog/git-workflow-release-cycle-4maintenance_1606709268508.png)

当用户反馈系统有bug时，为了处理bug，需要从master中创建出维护分支hotfix，等到bug修复完成，需要合并回master

```ssh
# 基于master新建hotfix分支
git checkout -b hotfix-v0.1.0.1 master

```

当问题修复完成，并测试通过后，将hotfix分支合并到master分支和develop分支，并打一个标签。

将hotfix分支合并到master分支:

```ssh
# 切换回master分支
git checkout master
# 将维护分支与当前分支合并
git merge --on-off hotfix-v0.1.0.1
# 将合并后的内容推送至远程仓库
git push

```

将hotfix分支合并到develop分支,合并完成后删除hotfix分支：

```ssh
# 切换到develop分支
git checkout develop
# 将维护分支与当前分支合并
git merge --on-off hotfix/v0.1.1
# 将合并后的内容推送至远程仓库
git push
# 至此，该维护分支可以删除了
git branch -d hotfix-v0.1.1

```

打上Tag：

```ssh
# 创建tag
git tag -a v0.1.1 -m '修复了***' master
# 推送至远程仓库 
git push --tags

```

到此，Gitflow工作流的流程基本解释完了，但还是需要说明一下，任何工作流都只是参考，实际生产中还需根据实际情况灵活应用。