一，GitFlow介绍

1.1 什么是GitFlow

GitFlow 是一种 Git 工作流，这个工作流程围绕着 project 的发布 (release) 定义了一个严格的如何建立分支的模型。它是团队成员遵守的一种代码管理方案 。

Git 建分支是非常 cheap 的，我们可以任意建立分支，对任意分支再分支，分支开发完后再合并。

比较推荐、多见的做法是特性驱动 (Feature Driven) 的建立分支法(Feature Branch Workflow)。

简而言之，就是每一个特性 (feature) 的开发并不直接在主干上开发，而是在分支上开发，分支开发完毕后再合并到主干上。

这样做的好处是：

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

GitFlow 则在这个基础上更进一步，规定了如何建立、合并分支，如何发布，如何维护历史版本等工作流程。

1.2 GitFlow常用分支

1.3 Git flow中分支介绍

Git Flow 的核心就是分支 (Branch），通过在项目的不同阶段对分支的不同操作（包括但不限于创建、合并、变基等）来实现一个完整的高效率的工作流程。Git Flow 模型中定义了主分支和辅助分支两类分支。

• 其中主分支包含：master 分支和 develop 分支，用于组织与软件开发、部署相关的活动；

• 辅助分支包含：feature 分支、release 分支、hotfix 分支

  以及其他自定义分支，是为了解决特定的问题而进行的各种开发活动。

  与主分支不同，这些分支总是有有限的生命时间，因为它们最终将被移除。

1.3.1 Master分支

主要分支上存放的是最稳定的正式版本，并且该分支的代码应该是随时可在生产环境中使用的代码。当一个版本开发完毕后，产生了一份新的稳定的可供发布的代码时，主要分支上的代码要被更新。同时，每一次更新，都需要在主要分支上打上对应的版本号。

任何人不允许在主要分支上进行代码的直接提交，只接受其他分支的合入。原则上主要分支上的代码必须是合并自经过多轮测试及已经发布一段时间且线上稳定的预发分支。

master 分支只存放历史发布 (release) 版本的源代码。即用于存放对外发布的版本，任何时候在这个分支获取到的都是稳定的已发布的版本。各个版本通过 tag 来标记。上图里的 v0.1 和 v0.2 就是 tag。

1.3.2 Develop分支

开发分支是主开发分支，其上更新的代码始终反映着下一个发布版本需要交付的新功能。当开发分支到达一个稳定的点并准备好发布时，应该从该点拉取一个预发分支并附上发布版本号。也有人称开发分支为集成分支，因为会基于该分支和持续集成工具做自动化的构建。

开发分支接受其他辅助分支的合入，最常见的就是功能分支，开发一个新功能时拉取新的功能分支，开发完成后再并入开发分支。需要注意的是，合入开发的分支必须保证功能完整，不影响开发分支的正常运行。

develop 分支则用来整合各个 feature 分支。开发中的版本的源代码存放在这里。即用于日常开发，存放最新的开发版。

1.3.3 Feature分支

功能分支一般命名为 Feature/xxx，用于开发即将发布版本或未来版本的新功能或者探索新功能。该分支通常存在于开发人员的本地代码库而不要求提交到远程代码库上，除非几个人合作在同一个功能分支开发。

功能分支只能拉取自开发分支，开发完成后要么合并回开发分支，要么因为新功能的尝试不如人意而直接丢弃。

每一个特性 (feature) 都必须在自己的分支里开发，feature 分支派生自 develop 分支。

feature 分支只存在于开发者本地，不能被提交到远程库。当 feature 开发完毕后，要合并回 develop 分支。feature 分支永远不会和 master 分支打交道。

1.3.4 Release分支

预发分支一般命名为 Release/1.2（后面是版本号），该分支专为测试—发布新的版本而开辟，允许做小量级的 Bug 修复和准备发布版本的元数据信息（版本号、编译时间等）。通过创建预发分支，使得开发分支得以空闲出来接受下一个版本的新的功能分支的合入。

预发分支需要提交到服务器上，交由测试工程师进行测试，并由开发工程师修复 Bug。同时根据该分支的特性我们可以部署自动化测试以及生产环境代码的自动化更新和部署。

预发分支只能拉取自开发分支，合并回开发分支和主要分支。

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

我们用这个分支干所有和发布有关的事情，比如：

把这个分支打包给测试人员测试

在这个分支里修复 bug

编写发布文档

所以，在这个分支里面绝对不会添加新的特性。

当和发布相关的工作都完成后，release 分支合并回 develop 和 master 分支。

单独搞一个 release 分支的好处是，当一个团队在做发布相关的工作时，另一个团队则可以接着开发下一版本的东西。

1.3.5 hotfix分支

热修复分支一般命名为Hotfix/1.2.1（后面是版本号），当生产环境的代码（主要分支上代码）遇到严重到必须立即修复的缺陷时，就需要从主要分支上指定的 tag 版本（比如 1.2）拉取热修复分支进行代码的紧急修复，并附上版本号（比如 1.2.1）。这样做的好处是不会打断正在进行的开发分支的开发工作，能够让团队中负责功能开发的人与负责代码修复的人并行、独立的开展工作。

热修复分支只能主要分支上拉取，测试通过后合并回主要分支和开发分支。

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

develop 分支上包含还未验证过的 feature

用户未必需要 develop 上的 feature

develop 还不能马上发布，而客户急需这个 bug 的修复。

这时就需要新建 hotfix 分支，hotfix 分支派生自 master 分支，仅仅用于修复 bug，当 bug 修复完毕后，马上回归到 master 分支，然后发布一个新版本，比如，v0.1.1。

同时 hotfix 也要合并回 develop 分支，这样 develop 分支就能享受到 bug 修复的好处了。

1.4 GitFlow工作流程

二，GitFlow模拟

下面的例子将演示 Gitflow 流程如何被用来管理一次产品发布。假设你已经创建好了一个中央仓库。

2.1 创建develop分支

第一步是给默认的 master 配备一个 develop 分支。一种简单的做法是：让一个开发者在本地建立一个空的 develop 分支，然后把它推送到服务器。

git branch develop
git push -u origin develop

develop 分支将包含项目的所有历史，而 master 会是一个缩减版本。现在，其他开发者应该克隆（clone）中央仓库，并且为 develop 创建一个追踪分支。

git clone 仓库url
git checkout -b develop origin/develop

到现在，所有人都把包含有完整历史的分支（develop）在本地配置好了。

2.2 小马和小明开始开发新功能

我们的故事从小马和小明要分别开发新功能开始。他们俩各自建立了自己的分支。

注意，他们在创建分支时，父分支不能选择 master，而要选择 develop。

git checkout -b xiaoma-feature develop

他们俩都在自己的功能开发分支上开展工作。通常就是这种 Git 三部曲：edit，stage，commit：

git status
git add <some-file>
git commit

2.3 小马把他的功能开发好了

在提交过几次代码之后，小马觉得她的功能做完了。

• 如果她所在的团队使用“拉拽请求”，此刻便是一个合适的时机她可以提出一个将她所完成的功能合并入 develop 分支的请求。

• 或者，她可以自行将她的代码合并入本地的 develop 分支，然后再推送到中央仓库，像这样：

  git pull origin develop
  git checkout develop
  git merge some-feature
  git push
  git branch -d some-feature
  

  第一条命令确保了本地的 develop 分支拥有最新的代码——这一步必须在将功能代码合并之前做！注意，新开发的功能代码永远不能直接合并入 master。必要时，还需要解决在代码合并过程中的冲突。

2.4 小马准备第一次发布

尽管小明还在忙着开发他的功能，小马却可以开始准备这个项目的第一次正式发布了。类似于功能开发，她使用了一个新的分支来做产品发布的准备工作。在这一步，发布的版本号也最初确定下来。

git checkout -b release-0.1 develop

这个分支专门用于发布前的准备，包括一些清理工作、全面的测试、文档的更新以及任何其他的准备工作。它与用于功能开发的分支相似，不同之处在于它是专为产品发布服务的。

一旦小马创建了这个分支并把它推向中央仓库，这次产品发布包含的功能也就固定下来了。任何还处于开发状态的功能只能等待下一个发布周期。

2.5 小马完成了发布

一切准备就绪之后，小马就要把发布分支合并入 master 和 develop 分支，然后再将发布分支删除。注意，往 develop 分支的合并是很重要的，因为开发人员可能在发布分支上修复了一些关键的问题，而这些修复对于正在开发中的新功能是有益的。再次提醒一下，如果小马所在的团队强调代码评审（Code Review），此时非常适合提出这样的请求。

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，你都应该随即打上合适的标签。

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

2.6 用户发现了一个bug

当一次发布完成之后，小马便回去与小明一起开发其他功能了。突然，某个用户提出抱怨说当前发布的产品里有一个 bug。为了解决这个问题，小马（或者小明）基于 master 创建了一个用于维护的分支。她在这个分支上修复了那个 bug，然后把改动的代码直接合并入 master。

git checkout -b issue-#001 master
\# Fix the bug
git checkout master
git merge issue-#001
git push

跟用于发布的分支一样，在维护分支上的改动也需要合并入 develop 分支，这一点是很重要的！因此，小马务必不能忘了这一步。随后，她就可以将维护分支删除。

git checkout develop
git merge issue-#001
git push
git branch -d issue-#001

三，使用SourceTree模拟GitFlow流程

Sourcetree 下载地址：Sourcetree

3.1 创建本地仓库+远程仓库

3.2 创建git flow

1. 在 cmd 中对 git 先初始化

   git init
   

2. 先提交一次，让 git 创建出 master 分支

   git add *
   git commit -m init *
   

3. 创建 git flow
   

4. 初始化完成效果
   

3.3 添加远端仓库

将项目推送到远端，给远端初始化

3.4 开发功能模块

点击 gitflow 图标，new 一个 feature 分支，然后输入当前要做的模块名称。

注意：此处最好在最新的 develop 分支上，进行创建 feature，这样确保更少的冲突。

完成之后，可见当前分支的情况

3.5 完成功能模块

1. 将我们的更改放入暂存区
   

2. 提价我们的更改，写下备注
   

3. 在合并前我们需要先把远端最新的开发分支拉取到本地

4. 点击 gitflow 选择完成功能
   

5. 然后勾选完点击确定
   

6. 将本地更改推送到仓库

3.6 发布版本

1. 选择 git flow，选择发布版本
   

2. 输入要发布的版本号，此处的输入会车位版本 tag 信息

3. 然后将项目中需要改版本的号的文件进行相对应的提交和修改。完成之后 commit 到当前的 release 分支上。如果有小 bug 修复也可以在 release 中先修改

4. 修改完毕后，点击 git flow，完成发布版本
   

5. 将当前版本打 tag：1.0
   

点击完后后，会将当前的 release 分支合并到 develop，master 分支，是否要推倒 origin，由 coder 自己决定。这样做的好处是，master 分支上的每个节点，都是一个版本。方便查阅。

注意：此处发布时，需要 team 中，负责发布的 coder 去操作，避免多人发布，造成版本号，Tag 混乱

3.7 热修复

如果版本发出后，出现了一个 bug，需要紧急的去修改，则需要使用 new 一个 hotfix，去进行开发。

1. 点击 git flow，选择新建热修复补丁
   

2. 填写补丁名
   

3. 在修复完提交后，选择 git flow 完成修复
   

4. 填写信息，完成修复
   

5. 完成之后，会自动合并到本地的 master，develop 分支上，至于是否要 push 到 origin 由 Coder 自行决定。