【转】git-flow 的工做流程

git-flow 的工做流程

当在团队开发中使用版本控制系统时，商定一个统一的工做流程是相当重要的。Git 的确能够在各个方面作不少事情，然而，若是在你的团队中尚未能造成一个特定有效的工做流程，那么混乱就将是不可避免的。

基本上你能够定义一个彻底适合你本身项目的工做流程，或者使用一个别人定义好的。

在这章节中咱们将一块儿学习一个当前很是流行的工做流程 git-flow。

什么是 git-flow？

一旦安装安装 git-flow，你将会拥有一些扩展命令。这些命令会在一个预约义的顺序下自动执行多个操做。是的，这就是咱们的工做流程！

git-flow 并非要替代 Git，它仅仅是很是聪明有效地把标准的 Git 命令用脚本组合了起来。

严格来说，你并不须要安装什么特别的东西就可使用 git-flow 工做流程。你只须要了解，哪些工做流程是由哪些单独的任务所组成的，而且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就能够了。固然，若是你使用 git-flow 脚本就会更加方便了，你就不须要把这些命令和顺序都记在脑子里。

安装 git-flow

近些年来出现了不少不一样的安装方法。在本章节中咱们会使用当前最流行的一种： AVH Edition。

要了解安装 git-flow 细节，请阅读下面这个文档 official documentation。

在项目中设置 git-flow

当你想把你的项目 “切换” 到 git-flow 上后，Git 仍是能够像往常同样工做的。这彻底是取决于你在仓库上使用特殊的 git-flow 命令或是普通的 Git 命令。换句话说，git-flow 它不会以任何一种戏剧性的方式来改变你的仓库。

话虽如此，git-flow 却存在一些限制。让咱们开始在一个新的项目上初始化它吧，以后咱们就会有所发现：

$ git flow init
Initialized empty Git repository in /Users/tobi/acme-website/.git/
Branch name for production releases: [master]
Branch name for "next release" development: [develop]

How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]

当在项目的根目录执行 “git flow init” 命令时（它是否已经包括了一个 Git 仓库并不重要），一个交互式安装助手将引导您完成这个初始化操做。听起来是否是有点炫，但实际上它只是在你的分支上配置了一些命名规则。
尽管如此，这个安装助手仍是容许你使用本身喜欢的名字。我强烈建议你使用默认的命名机制，而且一步一步地肯定下去。

分支的模式

git-flow 模式会预设两个主分支在仓库中：

• master 只能用来包括产品代码。你不能直接工做在这个 master 分支上，而是在其余指定的，独立的特性分支中（这方面咱们会立刻谈到）。不直接提交改动到 master 分支上也是不少工做流程的一个共同的规则。
• develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是_开发_的基础。另外，该分支也聚集全部已经完成的功能，并等待被整合到 master 分支中。

这两个分支被称做为 长期分支。它们会存活在项目的整个生命周期中。而其余的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据须要来建立的，当它们完成了本身的任务以后就会被删除掉。

让咱们开始探索一些在现实应用中可能遇到的案例吧！

功能开发

对于一个开发人员来讲，最日常的工做可能就是功能的开发。这就是为何 git-flow 定义了不少对于功能开发的工做流程，从而来帮助你有组织地完成它。

开始新功能

让咱们开始开发一个新功能 “rss-feed”：

$ git flow feature start rss-feed
Switched to a new branch 'feature/rss-feed'

Summary of actions:
- A new branch 'feature/rss-feed' was created, based on 'develop'
- You are now on branch 'feature/rss-feed'

概念

在这些命令的输出文本中，git-flow 会对刚刚完成的操做打印出一个颇有帮助的概述

当你须要帮助的时候，你能够随时请求帮助。例如：

$ git flow feature help

正如上面这个新功能同样，git-flow 会建立一个名为 “feature/rss-feed” 的分支（这个 “feature/” 前缀 是一个可配置的选项设置）。你已经知道了，在你作新功能开发时使用一个独立的分支是版本控制中最重要的规则之一。
git-flow 也会直接签出这个新的分支，这样你就能够直接进行工做了。

完成一个功能

通过一段时间艰苦地工做和一系列的聪明提交，咱们的新功能终于完成了：

$ git flow feature finish rss-feed
Switched to branch 'develop'
Updating 6bcf266..41748ad
Fast-forward
    feed.xml | 0
    1 file changed, 0 insertions(+), 0 deletions(-)
    create mode 100644 feed.xml
Deleted branch feature/rss-feed (was 41748ad).

最重要的是，这个 “feature finish” 命令会把咱们的工做整合到主 “develop” 分支中去。在这里它须要等待：

1. 一个在更普遍的 “开发” 背景下的全面测试。
2. 稍后和全部积攒在 “develop” 分支中的其它功能一块儿进行发布。

以后，git-flow 也会进行清理操做。它会删除这个当下已经完成的功能分支，而且换到 “develop” 分支。

管理 releases

Release 管理是版本控制处理中的另一个很是重要的话题。让咱们来看看如何利用 git-flow 建立和发布 release。

建立 release

当你认为如今在 “develop” 分支的代码已是一个成熟的 release 版本时，这意味着：第一，它包括全部新的功能和必要的修复；第二，它已经被完全的测试过了。若是上述两点都知足，那就是时候开始生成一个新的 release 了：

$ git flow release start 1.1.5
Switched to a new branch 'release/1.1.5'

请注意，release 分支是使用版本号命名的。这是一个明智的选择，这个命名方案还有一个很好的附带功能，那就是当咱们完成了release 后，git-flow 会适当地_自动_去标记那些 release 提交。

有了一个 release 分支，再完成针对 release 版本号的最后准备工做（若是项目里的某些文件须要记录版本号），而且进行最后的编辑。

完成 release

如今是时候按下那个危险的红色按钮来完成咱们的release了：

git flow release finish 1.1.5

这个命令会完成以下一系列的操做：

1. 首先，git-flow 会拉取远程仓库，以确保目前是最新的版本。
2. 而后，release 的内容会被合并到 “master” 和 “develop” 两个分支中去，这样不只产品代码为最新的版本，并且新的功能分支也将基于最新代码。
3. 为便于识别和作历史参考，release 提交会被标记上这个 release 的名字（在咱们的例子里是 “1.1.5”）。
4. 清理操做，版本分支会被删除，而且回到 “develop”。

从 Git 的角度来看，release 版本如今已经完成。依据你的设置，对 “master” 的提交可能已经触发了你所定义的部署流程，或者你能够经过手动部署，来让你的软件产品进入你的用户手中。

hotfix

不少时候，仅仅在几个小时或几天以后，当对 release 版本做作全面测试时，可能就会发现一些小错误。
在这种状况下，git-flow 提供一个特定的 “hotfix” 工做流程（由于在这里无论使用 “功能” 分支流程，仍是 “release” 分支流程都是不恰当的）。

建立 Hotfixes

$ git flow hotfix start missing-link

这个命令会建立一个名为 “hotfix/missing-link” 的分支。由于这是对产品代码进行修复，因此这个 hotfix 分支是基于 “master” 分支。
这也是和 release 分支最明显的区别，release 分支都是基于 “develop” 分支的。由于你不该该在一个还不彻底稳定的开发分支上对产品代码进行地修复。

就像 release 同样，修复这个错误固然也会直接影响到项目的版本号！

完成 Hotfixes

在把咱们的修复提交到 hotfix 分支以后，就该去完成它了：

$ git flow hotfix finish missing-link

这个过程很是相似于发布一个 release 版本：

• 完成的改动会被合并到 “master” 中，一样也会合并到 “develop” 分支中，这样就能够确保这个错误不会再次出如今下一个 release 中。
• 这个 hotfix 程序将被标记起来以便于参考。
• 这个 hotfix 分支将被删除，而后切换到 “develop” 分支上去。

仍是和产生 release 的流程同样，如今须要编译和部署你的产品（若是这些操做不是自动被触发的话）。

回顾一下

最后，在结束这个章节以前，我要再次强调几个重点。
首先，git-flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚原本捆绑了一系列 Git 命令来完成一些特定的工做流程。
其次，定义一个固定的工做流程会使得团队协做更加简单容易。不管是一个 “版本控制的新手” 仍是 “Git 专家”，每个人都知道如何来正确地完成某个任务。

记住，使用 git-flow 并非必须的。当积攒了必定的使用经验后，不少团队会再也不须要它了。当你能正确地理解工做流程的基本组成部分和目标的以后，你彻底能够定义一个属于你本身的工做流程。