Git工做流指南：Gitflow工做流

 

这节介绍的Gitflow工做流借鉴自在nvie的Vincent Driessen。

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

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

工做方式

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

历史分支

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

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

功能分支

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

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

发布分支

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

使用一个用于发布准备的专门分支，使得一个团队能够在完善当前的发布版本的同时，另外一个团队能够继续开发下个版本的功能。
这也打造定义良好的开发阶段（好比，能够很轻松地说，『这周咱们要作准备发布版本4.0』，而且在仓库的目录结构中能够实际看到）。

经常使用的分支约定：

用于新建发布分支的分支: develop
用于合并的分支: master
分支命名: release-* 或 release/*

维护分支

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

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

示例

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

建立开发分支

第一步为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

如今每一个开发都有了这些历史分支的本地拷贝。

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

这个示例中，小红和小明开始各自的功能开发。他们须要为各自的功能建立相应的分支。新分支不是基于master分支，而是应该基于develop分支：

git checkout -b some-feature develop

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

小红完成功能开发

添加了提交后，小红以为她的功能OK了。若是团队使用Pull Requests，这时候能够发起一个用于合并到develop分支。不然她能够直接合并到她本地的develop分支后push到中央仓库：

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

第一条命令在合并功能前确保develop分支是最新的。注意，功能决不该该直接合并到master分支。冲突解决方法和集中式工做流同样。

小红开始准备发布

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

git checkout -b release-0.1 develop

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

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

小红完成发布

一旦准备好了对外发布，小红合并修改到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分支上拉出了一个维护分支，提交修改以解决问题，而后直接合并回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