标准GitFlow工作流程

版本管理的挑战

虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：

• 如何开始一个Feature的开发，而不影响别的Feature？
• 由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
• 哪些分支已经合并回了主干？
• 如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
• 线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?

大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。

[TOC]

一、Git Flow 简介

Git Flow 是一个围绕项目开发发布的严格 git 分支模型，用于管理多人协作的大型项目中实现高效的协作开发，大致分为三种:

• Git Flow: 最原始的 Git Flow 分支模型
• Github Flow: Git Flow 的简化版，专门配合持续发布
• GitLab Flow: Git Flow 与 Github Flow 的结合版

关于三种 Git Flow 区别详情可参考大佬阮一峰的 Git 工作流程

二、 Git Flow 流程

Github Flow 和 GitLab Flow 对于持续发布支持比较好，但是原始版本的 Git Flow 对于传统的按照版本发布更加友好一些，所以以下主要说明以下 Git Flow 的工作流程；Git Flow 主要分支模型如下

上面这个官方图可能看起来不太直观，可参考下图：

在整个分支模型中 存在两个长期分支: develop 和 master，其中 develop 分支为开发分支，master 为生产分支；master 代码始终保持随时可以部署到线上的状态；develop 分支用于合并最新提交的功能性代码；具体的分支定义如下

• master: 生产代码，始终保持可以直接部署生产的状态
• develop: 开发分支，每次合并最新功能代码到此分支
• feature: 新功能分支，所有新开发的功能将采用 feature/xxxx 形式命名分支
• hotfixe: 紧急修复补丁分支，当新功能部署到了线上出现了严重 bug 需要紧急修复时，则创建 hotfixe/xxxx 形式命名的分支
• release: 稳定版分支，当完成大版本变动后，应该创建 release/xxxx 分支

在整个分支模型中，develop 分支为最上游分支，会不断有新的 feature 合并入 develop 分支，当功能开发达到完成所有版本需求时，则从 develop 分支创建 release 分支，release 后如没有发现其他问题，最终 release 会被合并到 master 分支以完成线上部署

Git Flow如何工作

初始分支

• 所有在Master分支上的Commit应该Tag
  
• Feature 分支分支名 feature/feature1分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，但是我们也可以保留
  
• Release分支分支名 release/release1分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
  
• 维护分支 Hotfix分支名 hotfix/hotfix1分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag
  

Git 命令：

1. 创建develop分支

• git branch develop git push -u origin develop

2. 开始新Feature开发

• git checkout -b some-feature develop

• git push -u origin some-feature 可选推送至远端

• git status

• git add some-file

• git commit

3. 完成Feature

• git pull origin develop
• git checkout develop
• git merge --no-ff some-feature
• git push origin develop
• git branch -d some-feature
• git push origin --delete some-feature取决于是否已将Feature提交到远端

4. 开始Release

• git checkout -b release-0.1.0 develop

5. 完成Release

• git checkout master
• git merge --no-ff release-0.1.0
• git push
• git checkout develop
• git merge --no-ff release-0.1.0
• git push git branch -d release-0.1.0
• git push origin --delete release-0.1.0 取决于是否已将Release提交到远端
• git tag -a v0.1.0 master
• git push --tags

6. 开始Hotfix

• git checkout -b hotfix-0.1.1 master

7. 完成Hotfix

• git checkout master
• git merge --no-ff hotfix-0.1.1
• git push
• git checkout develop
• git merge --no-ff hotfix-0.1.1
• git push
• git branch -d hotfix-0.1.1
• git tag -a v0.1.1 master
• git push --tags

三、Git Flow 工具

针对于 Git Flow，其手动操作 git 命令可能过于繁琐，所以后来有了 git-flow 工具；git-flow 是一个 git 扩展集； git-flow 安装以及使用具体请参考 git-flow 备忘清单，该文章详细描述了 git-flow 工具的使用方式

• 那么又有人做出了GUI工具，你只需要点击下一步就行，工具帮你干这些事。
  当你用Git-flow初始化后，基本上你只需要点击git flow菜单选择start feature, release或者hotfix, 做完后再次选择git flow菜单，点击Done Action.

个人推荐：SourceTree强大的图形化Git工作流（点点点），最主要是免费！

IDE集成参考

• JetBrain系列开发工具(如IDEA、WebStorm、PyCharm):
  • Settings>Plugins>Browse repositories，搜索Git Flow Integration安装；
  • 或访问JetBrain官方库下载，在Plugins>Install plugin from disk安装。
• VisualStudio系列开发工具：
  • 工具>扩展和更新，搜索GitFlow安装，详见Marketplace
• VS Code:
  • Extensions，搜索gitflow安装，完成后通过Command Palettee调用，建议同GitLens配合食用

四、GitLab 整合

以上 Git Flow 所有操作介绍的都是在本地操作，而正常我们在工作中都是基于 GitLab 搭建私有 Git 仓库来进行协同开发的，以下简述以下 Git Flow 配合 GitLab 的流程

4.1 开发 features

当开发一个新功能时流程如下:

• 本地 git flow feature start xxxx 开启一个 feature 新分支
• git flow feature publish xxxx 将此分支推送到远端以便他人获取 (可选)
• 完成开发后 GitLab 上向 develop 分支发起合并请求
• CI sonar 等质量检测工具扫描，其他用户 review 代码
• 确认无误后 master 权限用户合并其到 develop 分支
• 部署到测试环境以便测试组测试
• 如果测试不通过，则继续基于此分支开发，直到该功能开发完成

4.2 创建 release

当一定量的 feature 开发完成并合并到 develop 后，如所有 feature 都测试通过并满足版本需求，则可以创建 release 版本分支；release 分支流程如下

• 本地 git flow release start xxxx 开启 release 分支
• git flow release publish xxxx 将其推送到远端以便他人获取
• 继续进行完整性测试，出现问题继续修复，直到 release 完全稳定
• 从 release 分支向 master、develop 分支分别发起合并请求
• master 合并后创建对应的 release 标签，并部署生产环境
• develop 合并 release 的后期修改

4.3 紧急修复hotfix

当 master 某个 tag 部署到生产环境后，也可能出现不符合预期的问题出现；此时应该基于 master 创建 hotfix 分支进行修复，流程如下标准GitFlow工作流程

• 本地 git flow hotfix start xxxx 创建紧急修复分支
• 修改代码后将其推送到远端，并向 master、develop 分支发起合并
• develop 合并紧急修复补丁，如果必要最好再做一下测试
• master 合并紧急修复补丁，创建紧急修复 tag，并部署生产环境

参考

• Git 工作流程
• git-flow 备忘清单