转载

名词解释

Gitflow工作流(Gitflow Workflow)是2010年由Vincent Driessen在他的一篇博客里提出来的。它定义了一整套完善的基于Git分支模型的框架，结合了版本发布的研发流程，适合管理具有固定发布周期的大型项目。
和特性分支工作流相比，Gitflow工作流并没有引入任何新的概念。不同的地方在于，它强化了对Git分支模型的使用，结合产品或项目发布周期的特定需求，定义了各种不同类型的分支，每一种分支都有它自己特定的职责，并且分支之间什么时候、以什么样的方式交互，也都有相应的规则。下面我们就具体来看一下。

Master分支

Master分支作为唯一一个正式对外发布的分支，是所有分支里最稳定的。这是因为，只有经过了严格审核和测试，并且在当前发布计划里的特性，才会被合并到master分支。当某个版本发布的时候，我们通常还会为master分支加上带有相应版本号的tag。

Develop分支

Develop分支是根据master分支创建出来的，它作为一种集成分支(Integration Branch)，是专门用来集成开发完成的各种特性的。Develop分支通常具有更加详细和完整的提交历史，包括一些很细节的提交记录。而master分支则因为是面向版本发布的，所以它的提交历史会略去这些细节，显得比较精简。

Feature分支

Feature分支是根据develop分支创建出来的，Gitflow工作流里的每个新特性都有自己的feature分支，这一点和特性分支工作流是一样的。这些分支除了在开发人员的本地存在以外，也可以被推送到共享的远程Git库，作为工作备份，以及与其他人协同工作的基础。当特性开发结束以后，这些分支上的工作会被合并到develop分支。但feature分支从来不会直接和master分支打交道。

Release分支

当积累了足够多的已完成特性，或者预定的系统发布周期临近的时候，我们就会从develop分支创建出一个release分支，专门用来做和当前版本发布有关的工作。Release分支一旦开出来以后，就不允许再有新的特性被加入到这个分支了，只有bug修复或者文档编辑之类的工作才允许进入该分支。
Release分支上的内容最终会被合并到master分支，等版本发布的时候，我们通常还会为master分支加上带有相应版本号的tag。同时，release分支也会被合并到develop分支。在release分支活跃其间，develop分支也一直处于Open状态。Release分支上的内容代表当前版本在发布之前的准备工作，develop分支上的内容则代表下一个版本的开发工作，两者是可以并行展开的。

Hotfix分支

Hotfix分支不从是develop分支创建出来的，而是直接根据master分支创建得到的，其目的是为了给运行在生产环境中的系统快速提供补丁，同时确保不会给正在其他上分支进行的工作造成影响。当hotfix分支上的工作完成以后，可以合并到master分支和develop分支，以及当前的release分支。如果有版本的更新，也可以为master分支打上相应的tag。