什么是 GitFlow 工作流？

大家好，这里是修真院前端小课堂，今天给大家分享的是

《什么是 GitFlow 工作流？》

​

1. 背景介绍

什么是 Git 工作流？

Git 工作流你可以理解为工作中团队成员遵守的一种代码管理方案，在 Git 中有以下几种工作流方案作为方案指导。

1、集中式工作流

2、功能分支工作流

3、Gitflow 工作流

4、Forking 工作流

2. 知识剖析

1、集中式工作流

这种工作方式跟 svn 类似，它只有一个 master 分支，开发者会先把远程的仓库克隆到本地，之后的修 改和提交都在本地操作，直到在某个合适的时间点将本地的代码合入到远程 master。这种工作流比 较适合小团队，因为小团队可能不会太多的协作和合流的动作。

2、功能分支工作流

这种工作流关注功能开发，不直接往 master 提交代码保证它是稳定并且干净的，而是从 master 拉 取 feature 分支进行功能开发，团队成员根据分工拉取不同的功能分支来进行不同的功能开发，这样 就可以完全隔离开每个人的工作。当功能开发完成后，会向 master 分支发起 Pull Request，只有审 核通过的代码才真正允许合入 master，这样就加强了团队成员之间的代码交流。

3、Gitflow 工作流

它会相对复杂一点，但它非常适合用来管理大型项目的发布和维护，后面也会详细讲下这一块。 贯穿整个开发周期，master 和 develop 分支是一直存在的，master 分支可以被视为稳定的分支， 而 develop 分支是相对稳定的分支，特性开发会在 feature 分支上进行，发布会在 release 分支上 进行，而 bug 修复则会在 hotfix 分支上进行。

4、Forking 工作流

Forking 工作流对于开源项目贡献者一定不陌生了，它有一个公开的中央仓库，其他贡献 者可以 Fork（克隆）这个仓库作为你自己的私有仓库，开源项目维护者可以直接往中央仓库 push 代码，而代码贡献者只能将代码 push 到自己的私有仓库，只有项目维护者接受代码贡献 者往中央仓库发起的 pull request 才会真正合入。

3. 常见问题

Gitflow 工作流的工作方式？

4. 解决方案

Gitflow 工作流是经典模型，处于核心位置，体现了工作流的经验和精髓。

Gitflow 工作流通过为功能开发、发布准备和维护分配独立的分支，让发布迭代过程更流畅。严格的分支模型也为大型项目提供了一些非常必要的结构。

1、历史分支

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

2、功能分支

每个新功能位于一个自己的分支，这样可以 push 到中央仓库以备份和协作。 但功能分支不是从 master 分支上拉出新分支，而是使用 develop 分支作为父分支。 当新功能完成时，合并回 develop 分支。 新功能提交应该从不直接与 master 分支交互。 从各种含义和目的上来看，功能分支加上 develop 分支就是功能分支工作流的用法。但 Gitflow 工作流没有在这里止步。

3、发布分支

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

使用一个用于发布准备的专门分支，使得一个团队可以在完善当前的发布版本的同时，另一个团队可以继续开发下个版本的功能。 这也打造定义良好的开发阶段。

4、维护分支

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

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

5. 编码实战

由于本次均为理论性内容，所以以示例为主

下面的示例演示本工作流如何用于管理单个发布循环。假设你已经创建了一个中央仓库。

1、创建开发分支：

第一步为 master 分支配套一个 develop 分支。简单来做可以本地创建一个空的 develop 分支，push 到服务器上。 以后这个分支将会包含了项目的全部历史，而 master 分支将只包含了部分历史。 其它开发者这时应该克隆中央仓库，建好 develop 分支的跟踪分支： 现在每个开发都有了这些历史分支的本地拷贝。

2、小红和小明开始开发新功能：

这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。新分支不是基于 master 分支，而是应该基于 develop 分支，他们用老套路添加提交到各自功能分支上：编辑、暂存、提交。

3、小红完成功能开发

添加了提交后，小红觉得她的功能 OK 了。如果团队使用 Pull Requests，这时候可以发起一个用于合并到 develop 分支。 否则她可以直接合并到她本地的 develop 分支后 push 到中央仓。 在合并功能前确保 develop 分支是最新的。注意，功能决不应该直接合并到 master 分支。冲突解决方法和集中式工作流一样。

4、小红开始准备发布

这个时候小明正在实现他的功能，小红开始准备她的第一个项目正式发布。 像功能开发一样，她用一个新的分支来做发布准备。这一步也确定了发布的版本号。

这个分支是清理发布、执行所有测试、更新文档和其它为下个发布做准备操作的地方，像是一个专门用于改善发布的功能分支。 只要小红创建这个分支并 push 到中央仓库，这个发布就是功能冻结的。任何不在 develop 分支中的新功能都推到下个发布循环中。

5、小红完成发布

一旦准备好了对外发布，小红合并修改到 master 分支和 develop 分支上，删除发布分支。

合并回 develop 分支很重要，因为在发布分支中已经提交的更新需要在后面的新功能中也要是可用的。

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

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

6、最终用户发现 Bug

对外发布后，小红回去和小明一起做下个发布的新功能开发，直到有最终用户开了一个 Ticket 抱怨当前版本的一个 Bug。 为了处理 Bug，小红（或小明）从 master 分支上拉出了一个维护分支，提交修改以解决问题，然后直接合并回 master 分支。 就像发布分支，维护分支中新加这些重要修改需要包含到 develop 分支中，所以小红要执行一个合并操作。 然后就可以安全地删除这个分支了。

6. 扩展思考

SourceTree 里 GitFlow 的使用

1、初始化

SourceTree 会自动化进行一些操作，最明显的变化是项目代码库里自动增加了一个 develop 的分支。

将新创建的 develop 分支推送到远端仓库。

从此，代码库里就存在了两个永久性的分支：master 和 develop，未来所有的开发工作都围绕这两个分支进行派生跟合并。

2、之前提到，项目里有两个永久的分支：master 和 develop。这两个分支也被称为 “历史性” 分支，在其后的开发工作中， Gitflow 模型支持在 feature、release、hotfix 分支上折腾，这样也有效避免了不同类型的开发工作在代码层级的耦合和干扰。

这三个分支的用途、派生来源分支和合并目标分支如下：

feature，功能开发分支，用于承接具体功能需求的开发

派生于 develop

合并于 develop

hotfix，bug 修复分支，用于解决线上运行环境发现的 bug

派生于 master

合并于 master、develop

release，版本发布分支，用于完成发布准备的

派生于 develop

合并于 master、develop

跟 “历史性” 分支相反，这三类分支都是短期分支，针对他们的工作内容完成后，一般都要进行删除。工作内容完成的标识有两个：开发完成、合并完成，缺一不可。

3、我们使用 sourcetree 来实际演示一下（详细步骤请看视频）

4、三类临时性分支中，hotfix 和 release 的结果都要合并到 master 和 develop 中，为什么？因为它们的修改结果持续影响这后续的开发和维护，必须合并以保证代码的一致性。

如果你没有认识到这个特性很有用，那是因为你的开发工作还没有复杂到一个程度，一个必须要规避代码干扰、保证并行推进的程度。

对于小型项目和团队来说，基于 GIT 的中心式协作模型和特性分支模型就足够了；GitFlow 模型适合中型、大型项目和团队。

7. 参考文献

Git 工作流指南： https://github.com/xirong/my-git/blob/master/git-workflow-tutorial.md#231 - 工作方式

Git 工作流的一些经验分享：http://blog.csdn.net/wwj_748/article/details/55226044

SourceTree 里 GitFlow 的使用：http://www.cnblogs.com/niwanglong385/articles/5645835.html

8. 更多讨论
   一定要按照上述几种工作流来进行开发吗？

git 工作流是作为方案指导而不是条例规定。在展示了各种工作流可能的用法后，你可以从不同的工作流中挑选或揉合出一个满足你自己需求的工作流。

只有选用最合适自己团队的工作流才能有效的提高开发效率，上面提到的一些工作流模式都有各自 的适用场景，如何选用适合自己团队的工作流得结合团队成员的实际情况，看团队成员对于工作流的理解程度，还有对于工作流的执行程度。

编码实战演示的工作流只是可能用法的例子，而不是在实际工作中使用 Git 不可违逆的条例。 所以不要畏惧按自己需要对工作流的用法做取舍。不变的目标就是让 Git 为你所用。

问题：

1、hook 是什么？

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

2、SourceTree 的 GitFlow 工作流的合并与分支是自动设定的吗？

答：合适，在 SourceTree 中，使用 GitFlow 工作流会自动给功能分支、发布分支、修复分支设定从哪个分支拉取以及合并到哪些分支。

3、如何解决冲突？

答：解决冲突需要自己手动解决，选择 merge 还是选择哪个版本，merge 可以选择外部工具，也可以用 SourceTree 来解决。