一起了解 Git Flow 工作流程

Posted 2022-11-23 前端向朔

概述

在我们平时的开发工作中，肯定不是单兵作战，需要和其他同学一起协作，其中有一个很大的协作流程问题，就是我们代码托管库的工作流程管理问题，试想一下，如果没有一个统一的，大家一起遵循的工作流程，我们的代码托管库会出现什么问题。

最常见的就是代码冲突，就是多个人改了同一份代码；其次就是代码覆盖，大家都要用测试环境来验证自己的功能代码（每个人可能负责不同的功能），导致测试环境不稳定；还有一些新同学上来按自己想当然的想法，直接在 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

上面这条命令帮助我们做了哪些事呢？

1. 分支切换到 develop： git checkout develop
2. 基于 develop 分支，新建一个分支：git branch feature/message-board
3. 切换到前面新建的分支：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'

上面这条命令帮助我们做了哪些事呢？

1. 分支切换到 develop： git checkout develop
2. 合并开发完成的功能分支：git merge feature/message-board
3. 删除功能分支：git branch -d feature/message-board
4. 如果存在远程仓库，远程的分支也会删除：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'

上面这条命令帮助我们做了哪些事呢？

1. 分支切换到 develop： git checkout develop
2. 基于 develop 分支，新建一个分支：git branch release/1.1.0
3. 切换到前面新建的分支：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'

这个命令会完成如下一系列的操作：

1. 首先，Git Flow 会拉取远程仓库，以确保目前是最新的版本。
2. 然后，release 的内容会被合并到 master 和 develop 两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码。
3. 为便于识别和做历史参考，release 提交会被标记上这个 release 的名字（在我们的例子里是 “1.1.0”）。
4. 清理操作，版本分支会被删除，并且回到 develop。

上面这条命令帮助我们做了哪些事呢？

1. 分支切换到 master： git checkout master
2. 在 master 分支，将 release 分支合并到 master，git merge release/1.1.0
3. 打tag，tag 名为我们的版本号 v1.1.0
4. 分支切换到 develop ，git checkout develop
5. 在 develop 分支，将 tag 内容合并到 develop ，git merge release/1.1.0
6. 本地删除 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'

上面这条命令帮助我们做了哪些事呢？

1. 分支切换到 master： git checkout master
2. 基于 master 分支，新建一个分支：git branch hotfix/1.1.1
3. 切换到前面新建的分支：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'

1. 完成的改动会被合并到 master 中，同样也会合并到 develop 分支中，这样就可以确保这个错误不会再次出现在下一个 release 中。
2. 这个 hotfix 程序将被标记起来以便于参考。
3. 这个 hotfix 分支将被删除，然后切换到 develop 分支上去。
   还是和产生 release 的流程一样，现在需要编译和部署你的产品（如果这些操作不是自动被触发的话）。

总结

Git Flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。
其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。

记住，使用 Git Flow 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。

其他流程还有，比如 Github Flow 加入 PR 的 review 流程；阿里 AoneFlow 分支管理模式，可以达到持续集成，随意组合功能分支的目的。

流程规范是为了更高效的帮助团队实现目标，如果你觉得上面的流程对你目前的团队来说是个负担的话，可以考虑先不要采用了。

.END

参考：
git-flow 的工作流程