GitFlow ⼯作流

前言

Git 是一个开源分布式版本控制系统，它可以很方便的帮我们记录文件的改动，就像下面一样:

我们可以很快的跳到文件改动的某一个版本（就像时空穿梭一样）。

Git 在程序开发中，作为一个源码管理系统，免不了要多人协作。为了让协作更有效率，必须要有一个规范的流程。

GitFlow

GitFlow 是由 Vincent Driessen 提出的⼀个 git操作流程标准。

工作流程 在英语中，叫做 workflow 或者 flow ，原意是水流，比喻项目像水流那样顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。

Gitflow 工作流定义了一个围绕项目发布的严格分支模型。虽然比功能分支工作流复杂几分(Git工作流介绍 )，但提供了用于一个健壮的用于管理大型项目的框架。

Gitflow 工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。除了使用功能分支，在做准备、维护和记录发布也使用各自的分支。当然你可以用上功能分支工作流所有的好处：Pull Requests、隔离实验性开发和更高效的协作。

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

GitFlow的优势

GitFlow工作流程的优势在于：

• 还处于半成品状态的 feature 不会影响到主干
• 各个开发人员之间做自己的分支，互不干扰
• 主干永远处于可编译、可运行的状态

代码运行的环境：

一般来说，团队都会有至少这几个环境：

本地开发环境：

开发人员自测使用，也可以是自己本地部署的静态服务器。例如前端运行 npm server 类似的环境、后端 PHP 的LNMP环境，Golang直接起的进程服务之类的，本地环境运行的代码可以是任何分支的。

dev开发环境：

这个环境是用来开发分支 dev 产出的代码来部署的，唯一的、公用的

测试&预发布环境：

这个环境是用开发分支 release 产出的代码来部署的，唯一的、公用的

线上生产环境：

这个环境是用开发分支 master 产出的代码来部署的，唯一的、公用的

git 分支模型

先看一下分支的角色功能

分支的策略

dev 是公共的开发分⽀，不会合并到其他分⽀

所有的分⽀都是基于 master 分⽀检出

master：

保护分⽀，对应的就是⽣产环境的分⽀，它存储来发布版本的历史，各个版本通过 tag 来标记（git tag -a v0.1）

dev：

developt 开发分⽀&脏分⽀，对应的是⼤家共⽤的开发环境，上⾯的代码会部署到⼀个公共的开发环境，供开发⼈
员做⾃测，应付⼀些⽇常、⾮⽇常的调试。它可以用来整合各个功能 feature 分支，也方便给 master 分支上的所有提交分配一个版本号。

除了 master 和 develop 主分支线，其他的分支都是临时的分支，有一定的生命周期的，其余的工作流程分支都是围绕这两个分支之间的区别进行的。

feature-* ：

功能分⽀，具体功能开发

开发每个功能都必须新开个 feature 分支，feature 分支派生自 develop 分支。开发完成后要合并回 develop 分支。feature 分支永远不会和 master 分支打交道。

release：

待发布分支，所有开发完成的分⽀会申请合并到 release 分⽀，提供给测试⼈员测试

release 分支不是一个放正式发布产品的分支，可以理解为“预发布”或者“待发布”分支。

当开发的功能完成并满足发布的条件时，将这些满足条件的 feature 分支合并到 develop 分支上，然后从 develop 分支开出一个 release 分支，开始准备一个发布版本。

在 release 分支上，不能再添加新的功能，但是我们可以:

1. 将分支打包给测试人员测试
2. 在这个分支上修改bug
3. 编写发布文档

当到发布日时，发布相关的工作都完成后，release 分支合并到 master 分支，并打出版本标签，发布完成后，release 分支合还要并回到 develop 分支。

hotfix-*：

bug紧急修复分⽀，维护分支 ，可以直接合并到 master。

项目发布后或多或少会有一些 bug 存在，而 bug 的修复工作并不适合在 develop 上做，这是因为：

1. develop分支上可能包含还未验证过的 feature
2. 用户未必需要 develop 上的 feature
3. develop 还不能马上发布，而客户急需这个 bug 的修复。

这个分支是唯一一个开放过程中直接从 master 分支派生来的分支。

快速的修复问题后，hotfix 分支应该被合并回 master 分支，同时也要合并回 develop 分支，这样 develop 分支也能享受到 bug 修复的好处。然后 master 分支需要打一个版本标签，例如 v0.11。

历史分支

相对使用仅有的一个master 分支，Gitflow 工作流使用2个分支来记录项目的历史。master 分支存储了正式发布的历史，而 develop 分支作为功能的集成分支。这样也方便 master 分支上的所有提交分配一个版本号。

剩下要说明的问题围绕着这两个分支的区别展开。

功能分支

每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。但功能分支不是从 master 分支上拉出新分支，而是使用 develop 分支作为父分支。当新功能完成时，合并回develop分支。新功能提交应该从不直接与 master 分支交互。

注意，从各种含义和目的上来看，功能分支加上 develop 分支就是功能分支工作流的用法。但 Gitflow 工作流没有在这里止步。

发布分支

一旦 develop 分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，就从 develop 分支上 fork 一个发布分支。新建的分支用于开始发布循环，所以从这个时间点开始之后新的功能不能再加到这个分支上 —— 这个分支只应该做 Bug 修复、文档生成和其它面向发布任务。一旦对外发布的工作都完成了，发布分支合并到 master 分支并分配一个版本号打好 Tag。另外，这些从新建发布分支以来的做的修改要合并回 develop分支。

使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。

这也打造定义良好的开发阶段（比如，可以很轻松地说，『这周我们要做准备发布版本4.0』，并且在仓库的目录结构中可以实际看到）。

维护分支

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

为 Bug 修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。你可以把维护分支想成是一个直接在 master 分支上处理的临时发布。

GitFlow的命名约定

• 主分支名称：master
• 主开发分支名称：develop
• 标签（tag）名称：v##，如：v1.0.0
• 新功能开发分支名称：feature-## or feature/##，如：feature-games或feature/games
• 发布分支名称：release-## or release/##，如：release-1.0.0或release/1.0.0
• 维护分支名称：hotfix-## or **hotfix/## **，如：hotfix-update或hotfix/update

示例

下面演示了 GitFlow 工作流如何用于管理单个发布循环。

假设你已经创建了一个中央仓库。

创建开发分支

第一步为 master 分支配套一个 develop 分支。简单来做可以本地创建一个空的 develop 分支，push 到服务器上：

git branch develop
git push -u origin develop

以后这个分支将会包含了项目的全部历史，而 master 分支将只包含了部分历史。其它开发者这时应该克隆中央仓库，建好 develop 分支的跟踪分支：

git clone ssh://user@host/path/to/repo.git
git checkout -b develop origin/develop

现在每个开发都有了这些历史分支的本地拷贝。

开发新功能 feature分支

多个开发人员开始各自的功能开发，他们需要为各自的功能创建相应的分支。新分支不是基于 master 分支，而是应该基于 develop 分支：

git checkout -b some-feature develop

他们添加提交到各自功能分支上：编辑、暂存、提交：

git status

git add

git commit

完成功能开发（合并feature分支到develop）

添加了提交后，这时候觉得功能OK了。如果团队使用 Pull Requests，这时候可以发起一个用于 feature 分支合并到 develop 分支的允许，然后直接合并到本地的 develop 分支后 push 到中央仓库：

git pull origin develop

git checkout develop

git merge some-feature

git push

git branch -d some-feature

第一条命令在合并功能前确保 develop 分支是最新的。

注意，新功能决不应该直接合并到 master 分支。合并可能会有冲突，应该谨慎处理冲突。冲突解决方法和集中式工作流一样。

开始准备发布 新建待发布分支release

这个时候其他的工作人员正在进行他的功能开发，而你可以准备自己的功能发布。像功能开发一样，可以使用一个新的分支来做发布准备，基于 develop 分支新建一个待发布分支 release，这一步也确定了发布的版本号：

git checkout -b release-0.1 develop

这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支。

创建这个分支并 push 到中央仓库，这个发布就是功能冻结的。任何不在 develop 分支中的新功能都推到下个发布循环中。

完成发布 release分支合并到master发布

一旦准备好了对外发布，就将 release 分支合并修改到 master 分支和 develop 分支上，并删除发布分支。合并回到 develop 分支很重要，因为在发布分支中已经提交的更新需要在后面的新功能中也要是可用的。另外，如果团队要求Code Review，这是一个发起Pull Request的理想时机。

git checkout master

git merge release-0.1

git push

git checkout develop

git merge release-0.1

git push

git branch -d release-0.1

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

git tag -a 0.1 -m "Initial public release" master

git push --tags

Git有提供各种勾子（hook），即仓库有事件发生时触发执行的脚本。可以配置一个勾子，在你 push 中央仓库的 master 分支时，自动构建好对外发布。

发现Bug

对外发布后，开发人员准备做下个发布新功能的开发，直到有用户开了一个 Ticket 抱怨当前版本的一个 Bug。为了处理 Bug，需要从 master 分支上拉出了一个维护分支 hotfix，提交修改以解决问题，然后合并回 master 分支：

git checkout -b hotfix/v0.1.0.1 master

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

将 hotfix 分支合并到master分支:

git checkout master

git merge --on-off hotfix/v0.1.0.1

git push

就像发布分支，维护分支中新加这些重要修改需要包含到 develop 分支中，所以要执行一个合并操作。然后就可以安全地删除这个分支了：

git checkout develop

git merge --on-off hotfix/v0.1.1

git push

git branch -d hotfix/v0.1.1

打标签：

git tag -a v0.1.1 -m 'Initial public release' master

git push --tags

⼯作流程

1. 接到需求⽂档，做评审后分配个每个⼈或⼩组的功能开发，相关⼈员从master 检出功能分⽀
2. 开发的时候除了会在本地测试，有需要还会合并到dev分⽀，在公共的开发环境去⾃⼰做测试
3. 因为在开发功能的期间，可能有hotfix完成合并到master，合并代码的时候习惯merge⼀下master，防⽌冲突等
4. ⾃测完成之后，申请合并到release，合并成功后部署到测试环境后通知测试⼈员做测试
5. 测试通过后，release申请合并到master，准备上线
6. 如果测试不通过，在功能分⽀修改后重新merge
7. 上线成功稳定后删除对应的功能分⽀，dev 合并最新的master分⽀

GitFlow工具

GitFlow 不仅仅是一种规范，还提供了一套方便的工具。大大简化了执行 GitFlow 的过程。

OSX 安装

brew install git-flow

Debian/Ubuntu Linux 安装

apt-get install git-flow

Windows(cygwin） 安装

wget -q -O - --no-check-certificate https://github.com/nvie/gitflow/raw/develop/contrib/gitflow-installer.sh | bash

Initialize初始化

对一个git仓库配置一下git flow。主要是一些命名规范，比如 feature 分支的前缀，hotfix 分支的前缀等。一般用默认值就行。

git flow init

新建feature分支

从 develop 开启一个新的分支：

git flow feature start MYFEATURE

这个命令会从 develop 分出一个分支，然后切换到这个分支上面。

合并 feature 分支到 develop

一个feature分支开发完毕后，要做以下事情：

• 把 MYFEATURE 合并到 develop
• 把这个分支删除
• 切换回develop分支

git flow feature finish FEATURE_NAME

把feature分支推送到服务器

如果你想让别人和你一起开发 MYFEATURE 分支，那就把这个分支 push 到服务器上

git flow feature publish MYFEATURE

获得一个别人 push 到服务器上的 feature 分支：

git flow feature pull origin MYFEATURE

新建release分支

git flow release start RELEASE

把feature分支推送到服务器

git flow release publish RELEASE

合并release分支到master和develop

• 把release分支合并到master
• 给本次发布打tag
• 同时把release分支合并回develop
• 删除release分支

git flow release finish RELEASE

最后把 tag push 到服务器

git push --tags

新建hotfix分支

git flow hotfix start VERSION

结束一个 hotfix 分支，和 release 一样，同时合并回 develop 和 master：

git flow hotfix finish VERSION

基础命令

# 初始化
git flow init

# 开始新Feature
git flow feature start MYFEATURE

# Publish一个Feature(也就是push到远程)
git flow feature publish MYFEATURE

# 获取Publish的Feature:
git flow feature pull origin MYFEATURE

# 完成一个Feature
git flow feature finish MYFEATURE

# 开始一个Release
git flow release start RELEASE [BASE]

# Publish一个Release
git flow release publish RELEASE

# 发布Release:
git flow release finish RELEASE
# 别忘了提交
git push --tags

# 开始一个Hotfix:
git flow hotfix start VERSION [BASENAME]

# 发布一个Hotfix 
git flow hotfix finish VERSION