什么是GITFLOW工作流？

2017-10-23 本文已影响0人古碑先生

大家好，我是IT修真院北京分院第22期学员，一枚正直善良的web程序员。

1.背景介绍

什么是Git工作流？

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

1、集中式工作流

2、功能分支工作流

3、Gitflow工作流

4、Forking工作流

2.知识剖析

集中式工作流:

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

3.常见问题

Gitflow工作流的工作方式?
4.解决方案

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

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

历史分支

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

功能分支

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

发布分支

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

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

维护分支

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

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

5.编码实战
由于本次均为理论性内容，所以以示例为主

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

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

小红和小明开始开发新功能

这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支。

新分支不是基于master分支，而是应该基于develop分支，

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

小红完成功能开发

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

小红开始准备发布

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

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

小红完成发布

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

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

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

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

最终用户发现Bug

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

最终用户发现Bug

6.扩展思考

SourceTree里GitFlow的使用

1、初始化

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

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

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

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

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

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

派生于develop

合并于develop

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

派生于master

合并于master、develop

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

派生于develop

合并于master、develop

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

我们使用sourcetree来实际演示一下

三类临时性分支中，hotfix和release的结果都要合并到master和develop中，为什么？因为它们的修改结果持续影响这后续的开发和维护，必须合并以保证代码的一致性。如果你没有认识到这个特性很有用，那是因为你的开发工作还没有复杂到一个程度，一个必须要规避代码干扰、保证并行推进的程度。对于小型项目和团队来说，基于GIT的中心式协作模型和特性分支模型就足够了；GitFlow模型适合中型、大型项目和团队。

7.参考文献

参考一：Git工作流指南

参考二：Git 工作流的一些经验分享

参考三：SourceTree里GitFlow的使用

8.更多讨论

1.这个工作流是必须的吗？by雪飞

不，这只是一个开发流程的规范，你不按照他照样可以开发，比如咱们官网的开发流程就不是这样。

2.那咱们官网开发流程是什么。 by婷婷

先理一下葡萄藤的开发流程；

三个文件夹：后端，前台，后台，前后台文件夹里有各自的branch，tag，trunk，trunk放主要开发的版本，tag用来放进行功能升级后的版本号，在wiki上登记发布功能，版本号，回滚版本号，各个负责人名字，截图发邮件给运维发布到测试环境，经过测试人员测试通过后发布到线上环境。

3.trunk到底放着那个版本？by yg

大佬解释：trunk是正在玩的游戏，tag是保存的游戏记录