Gitflow工做流程

在工做场合实施Git的时候，有不少种工做流程可供选择，此时反而会让你手足无措。本文罗列了企业团队最经常使用的一些git工做流程，包括Centralized Workflow、Feature Branch Workflow、Gitflow Workflow、Forking Workflow。愿以此文抛砖引玉。

在你开始阅读以前，请记住：这些流程应被视做为指导方针，而非“铁律”。咱们只是想告诉你可能的作法。所以，若是有必要的话，你能够组合使用不一样的流程。

（本文主要介绍Gitflow Workflow……）

img

Vincent Driessen曾经写过一篇博文，题为“A successful Git branching model”（一个成功的Git分支模型）。Gitflow工做流程就是从这篇文章里来的。

Gitflow工做流程围绕项目发布定义了严格的分支模型。尽管它比Feature Branch Workflow更复杂一些，但它也为管理更大规模的项目提供了坚实的框架。

与Feature Branch Workflow比起来，Gitflow流程并无增长任何新的概念或命令。其特点在于，它为不一样的分支分配了很是明确的角色，而且定义了使用场景和用法。除了用于功能开发的分支，它还使用独立的分支进行发布前的准备、记录以及后期维护。固然，你仍是能充分利用Feature Branch Workflow的好处：拉拽请求（Pull Request）、隔离的试验以及更高效率的合做。

它是怎么工做的？

Gitflow流程仍然使用一个中央代码仓库，它是全部开发者的信息交流中心。跟其余的工做流程同样，开发者在本地完成开发，而后再将分支代码推送到中央仓库。惟一不一样的是项目中分支的结构。

用于记录历史的分支

Gitflow使用两个分支来记录项目开发的历史，而不是使用单一的master分支。在Gitflow流程中，master只是用于保存官方的发布历史，而develop分支才是用于集成各类功能开发的分支。使用版本号为master上的全部提交打标签（tag）也很方便。

img

事实上，Gitflow流程就是围绕这两个特色鲜明的分支展开的。

用于功能开发的分支

每个新功能的开发都应该各自使用独立的分支。为了备份或便于团队之间的合做，这种分支也能够被推送到中央仓库。可是，在建立新的功能开发分支时，父分支应该选择develop（而不是master）。当功能开发完成时，改动的代码应该被合并（merge）到develop分支。功能开发永远不该该直接牵扯到master。

img

注意：组合使用功能开发分支和develop分支的这种设计，其实彻底就是Feature Branch Workflow的理念。然而，Gitflow流程并不止于此。且看下文分解。

用于发布的分支

img

一旦develop分支积聚了足够多的新功能（或者预约的发布日期临近了），你能够基于develop分支创建一个用于产品发布的分支。这个分支的建立意味着一个发布周期的开始，也意味着本次发布不会再增长新的功能——在这个分支上只能修复bug，作一些文档工做或者跟发布相关的任务。在一切准备就绪的时候，这个分支会被合并入master，而且用版本号打上标签。另外，发布分支上的改动还应该合并入develop分支——在发布周期内，develop分支仍然在被使用（一些开发者会把其余功能集成到develop分支）。

使用专门的一个分支来为发布作准备的好处是，在一个团队忙于当前的发布的同时，另外一个团队能够继续为接下来的一次发布开发新功能。这也有助于清晰代表开发的状态，好比说，团队在汇报状态时能够轻松使用这样的措辞，“这星期咱们要为发布4.0版本作准备。”从代码仓库的结构上也能直接反映出来。经常使用的一些措辞还有：基于develop新建分支，合并入master；命名规则为：release-或release/

用于维护的分支

img

发布后的维护工做或者紧急问题的快速修复也须要使用一个独立的分支。这是惟一一种能够直接基于master建立的分支。一旦问题被修复了，所作的改动应该被合并入master和develop分支（或者用于当前发布的分支）。在这以后，master上还要使用更新的版本号打好标签。

这种为解决紧急问题专设的绿色通道，让团队没必要打乱当前的工做流程，也没必要等待下一次的产品发布周期。你能够把用于维护的分支当作是依附于master的一种特别的发布分支。

举例说明 \

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

1. 建立develop分支

img

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

git branch develop git push -u origin develop

develop分支将包含项目的全部历史，而master会是一个缩减版本。如今，其余开发者应该克隆（clone）中央仓库，而且为develop建立一个追踪分支。

git clone ssh://user@host/path/to/repo.git git checkout -b develop origin/develop

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

2. 小马和小明开始开发新功能

img

咱们的故事从小马和小明要分别开发新功能开始。他们俩各自创建了本身的分支。注意，他们在建立分支时，父分支不能选择master，而要选择develop。

git checkout -b some-feature develop

他们俩都在本身的功能开发分支上开展工做。一般就是这种Git三部曲：edit，stage，commit：

git status git add <some-file> git commit

3. 小马把她的功能开发好了

img

在提交过几回代码以后，小马以为她的功能作完了。若是她所在的团队使用“拉拽请求”，此刻即是一个合适的时机——她能够提出一个将她所完成的功能合并入develop分支的请求。要否则，她能够自行将她的代码合并入本地的develop分支，而后再推送到中央仓库，像这样：

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

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

4. 小马开始准备一次发布

img

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

git checkout -b release-0.1 develop

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

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

5. 小马完成了发布

img

一切准备就绪以后，小马就要把发布分支合并入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

Git支持钩子（hook）的功能，也就是说，在代码仓库里某些特定的事件发生的时候，能够执行一些预约义的脚本。所以，一种可行的作法是：在服务器端配置一个钩子，当你把master推送到中央仓库或者推送标签时，Git服务器能为产品发布进行一次自动的构建。

6. 用户发现了一个bug

img

当一次发布完成以后，小马便回去与小明一块儿开发其余功能了。忽然，某个用户提出抱怨说当前发布的产品里有一个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

原文连接：https://www.atlassian.com/git/workflows#!workflow-gitflow

 

本文做者：happydeer
原文连接：http://blog.csdn.net/happydeer/article/details/17618935
版权归做者全部，转载请注明出处