一起了解 Git Flow 工作流程
概述
在我们平时的开发工作中，肯定不是单兵作战，需要和其他同学一起协作，其中有一个很大的协作流程问题，就是我们代码托管库的工作流程管理问题，试想一下，如果没有一个统一的，大家一起遵循的工作流程，我们的代码托管库会出现什么问题。
最常见的就是代码冲突，就是多个人改了同一份代码；其次就是代码覆盖，大家都要用测试环境来验证自己的功能代码（每个人可能负责不同的功能），导致测试环境不稳定；还有一些新同学上来按自己想当然的想法，直接在 develop 分支修改内容，或者直接提交代码到 master 等各种问题。
以上，我们需要一套工作流程来解决团队成员之间协作存在的问题，这就是我们今天要讲的 Git Flow 工作流程。
什么是 Git Flow？
目前我们安装 git bash 默认就会自带安装了 Git Flow，我们将会拥有一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作。是的，这就是我们的工作流程！
Git Flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合了起来。
严格来讲，你并不需要安装什么特别的东西就可以使用 Git Flow 工作流程。你只需要了解，哪些工作流程是由哪些单独的任务所组成的，并且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然，如果你使用 Git Flow 脚本就会更加方便了，你就不需要把这些命令和顺序都记在脑子里。
在项目中设置 Git Flow
在一个项目里面，如果我们想要采用 Git Flow 工作流程，首先需要初始化一下。
输入命令之前，需要保证当前所在的仓库是有 master develop 这两个分支的。
第一次可能会比较慢，需要耐心等待一下。
$ git flow init -fd
# 参数含义 first define
Using default branch names.
Which branch should be used for bringing forth production releases?
- develop
- master
Branch name for production releases: [master]
Which branch should be used for integration of the "next release"?
- develop
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? [v]
这里列出了几种分支类型，以及该类型初始化定义的分支名包含的开头字段。执行完上面这句命令，我们在项目中就可以使用 Git Flow 流程来开发了。
分支的模式
Git Flow 模式会预设两个主分支在仓库中：
master只能用来包括产品代码。你不能直接工作在这个master分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到master分支上也是很多工作流程的一个共同的规则。develop是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是开发的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到master分支中。
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。
接下来我们就按流程感受一下，我们该如何在开发工作中运用 Git Flow 流程。
功能开发 Feature
对于一个开发人员来说，最平常的工作可能就是功能的开发。这就是为什么 Git Flow 定义了很多对于功能开发的工作流程，从而来帮助你有组织地完成它。
开始新功能
让我们开始开发一个新功能，比如网站留言板 “message-board”：
$ git flow feature start message-board
Switched to a new branch 'feature/message-board'
Summary of actions:
- A new branch 'feature/message-board' was created, based on 'develop'
- You are now on branch 'feature/message-board'
Now, start committing on your feature. When done, use:
git flow feature finish message-board
上面这条命令帮助我们做了哪些事呢？
- 分支切换到
develop：git checkout develop - 基于
develop分支，新建一个分支：git branch feature/message-board - 切换到前面新建的分支：
git checkout feature/message-board
说明：前面步骤 2,3 在平时的操作中也可以合并成：git checkout -b feature/message-board
基于上面的说明，我们可以注意一个问题，就是我们可以一开始自己主动切换到 develop 分支，并拉取最新的代码，因为 Git Flow 虽然会自动帮我们切换到 develop 分支，但是不会拉取最新代码，所以这里我们自己操作一下可以减小后面跟同事代码冲突的概率。
完成新功能
当我们在 feature 分支把一个功能开发完成的时候，我们接下来如何操作呢？
其实在上面我们创建的时候，已经有提示了。
$ git flow feature finish message-board
Switched to branch 'develop'
Already up to date.
Deleted branch feature/message-board (was e1c3446).
Summary of actions:
- The feature branch 'feature/message-board' was merged into 'develop'
- Feature branch 'feature/message-board' has been locally deleted
- You are now on branch 'develop'
上面这条命令帮助我们做了哪些事呢？
- 分支切换到
develop：git checkout develop - 合并开发完成的功能分支：
git merge feature/message-board - 删除功能分支：
git branch -d feature/message-board - 如果存在远程仓库，远程的分支也会删除：
git push origin :heads/feature/message-board
合并到 develop 分支的功能代码，会和其他功能代码，根据团队的迭代需求，统一发布。
版本管理（上线） Release
Release 管理是版本控制处理中的另外一个非常重要的话题。让我们来看看如何利用 Git Flow 创建和发布 release。
创建 release
当你认为现在在 develop 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：
$ git flow release start 1.1.0
Switched to a new branch 'release/1.1.0'
Summary of actions:
- A new branch 'release/1.1.0' was created, based on 'develop'
- You are now on branch 'release/1.1.0'
Follow-up actions:
- Bump the version number now!
- Start committing last-minute fixes in preparing your release
- When done, run:
git flow release finish '1.1.0'
上面这条命令帮助我们做了哪些事呢？
- 分支切换到
develop：git checkout develop - 基于
develop分支，新建一个分支：git branch release/1.1.0 - 切换到前面新建的分支：
git checkout release/1.1.0
说明：前面步骤 2,3 在平时的操作中也可以合并成：git checkout -b release/1.1.0
完成 release
在 release/1.1.0 分支上，我们可以发布测试环境，预发布环境等，来完成最后的验证，发现问题，及时在这个分支上进行修改，并提交验证，直到达到生产标准，我们就可以考虑结束 release 流程，来完成部署发版了。
$ git flow release finish 1.1.0
Switched to branch 'master'
Switched to branch 'develop'
Merge made by the 'recursive' strategy.
.env | 0
.env.development | 1 +
.env.production | 1 +
.env.sit | 2 +
README.md | 13 +-
# 中间省略文件更新列表
Deleted branch release/1.1.0 (was e1c3446).
Summary of actions:
- Release branch 'release/1.1.0' has been merged into 'master'
- The release was tagged 'v1.1.0'
- Release tag 'v1.1.0' has been back-merged into 'develop'
- Release branch 'release/1.1.0' has been locally deleted
- You are now on branch 'develop'
这个命令会完成如下一系列的操作：
- 首先，Git Flow 会拉取远程仓库，以确保目前是最新的版本。
- 然后，
release的内容会被合并到master和develop两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。 - 为便于识别和做历史参考，
release提交会被标记上这个release的名字（在我们的例子里是 “1.1.0”）。 - 清理操作，版本分支会被删除，并且回到
develop。
上面这条命令帮助我们做了哪些事呢？
- 分支切换到
master：git checkout master - 在
master分支，将release分支合并到master，git merge release/1.1.0 - 打tag，tag 名为我们的版本号
v1.1.0 - 分支切换到
develop，git checkout develop - 在
develop分支，将 tag 内容合并到 develop ，git merge release/1.1.0 - 本地删除
release/1.1.0分支，当前处于develop分支
从 Git 的角度来看，release 版本现在已经完成。依据你的设置，对 master 的提交可能已经触发了你所定义的部署流程，或者你可以通过手动部署，来让你的软件产品进入你的用户手中。
紧急线上修复 Hotfix
很多时候，仅仅在几个小时或几天之后，当对 release 版本作做线上测试时，可能就会发现一些小错误。
在这种情况下，Git Flow 提供一个特定的 hotfix 工作流程（因为在这里不管使用 “功能” 分支流程，还是 release 分支流程都是不恰当的）。
创建 hotfix
$ git flow hotfix start 1.1.1
Switched to a new branch 'hotfix/1.1.1'
Summary of actions:
- A new branch 'hotfix/1.1.1' was created, based on 'master'
- You are now on branch 'hotfix/1.1.1'
Follow-up actions:
- Start committing your hot fixes
- Bump the version number now!
- When done, run:
git flow hotfix finish '1.1.1'
上面这条命令帮助我们做了哪些事呢？
- 分支切换到
master：git checkout master - 基于
master分支，新建一个分支：git branch hotfix/1.1.1 - 切换到前面新建的分支：
git checkout hotfix/1.1.1
说明：前面步骤 2,3 在平时的操作中也可以合并成：git checkout -b hotfix/1.1.1
完成hotfix
紧急修复完成之后，我们可以结束本次修复了，这个过程有点类似 release 操作。
$ git flow hotfix finish '1.1.1'
Switched to branch 'develop'
Deleted branch hotfix/1.1.1 (was c40d1fe).
Summary of actions:
- Hotfix branch 'hotfix/1.1.1' has been merged into 'master'
- The hotfix was tagged 'v1.1.1'
- Hotfix branch 'hotfix/1.1.1' has been locally deleted
- You are now on branch 'develop'
- 完成的改动会被合并到
master中，同样也会合并到develop分支中，这样就可以确保这个错误不会再次出现在下一个release中。 - 这个
hotfix程序将被标记起来以便于参考。 - 这个
hotfix分支将被删除，然后切换到develop分支上去。
还是和产生release的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。
总结
Git Flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。
其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。
记住，使用 Git Flow 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。
其他流程还有，比如 Github Flow 加入 PR 的 review 流程；阿里 AoneFlow 分支管理模式，可以达到持续集成，随意组合功能分支的目的。
流程规范是为了更高效的帮助团队实现目标，如果你觉得上面的流程对你目前的团队来说是个负担的话，可以考虑先不要采用了。
.END
参考：
git-flow 的工作流程