# Git 流程规范
当在团队开发中使用版本控制系统时，制定一个统一的工作流程是至关重要的。如果在团队中没有形成一个特定有效的工作流程，那么混乱就将是不可避免的。
Git flow 是一个当前非常流行的工作流程，基于 Vincent Driessen 的分支模型 (opens new window) 定义了一个围绕项目发布的代码开发合并的管理流程，为不同的分支分配了明确的角色，并定义分支之间何时以及如何进行交互。
git-flow 并不是要替代 Git，它仅仅是非常聪明有效地把标准的 Git 命令用脚本组合起来，提供了一些扩展命令。这些命令会在一个预定义的顺序下自动执行多个操作，这就是我们所说的工作流程！
严格来讲，你并不需要安装什么特别的东西就可以使用 Git flow 工作流程。你只需要了解，这些工作流程是由哪些单独的任务所组成的，并且附带上正确的参数，以及在一个正确的顺序下简单执行那些对应的 Git 命令就可以了。当然，如果你使用 git-flow 脚本就会更加方便了，你就不需要把这些命令和顺序都记在脑子里。
# 开始使用
在 macOS 下使用 Homebrew 快速安装：
brew install git-flow-avh
为了自定义你的项目，Git flow 需要执行初始化。在项目根目录执行初始化命令：
git flow init
Initialized empty Git repository in /Users/vultur/next-docs/.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 会预设两个主分支在仓库中：
master 只能用来包括产品代码。你不能直接工作在这个
master分支上，而是在其他指定的、独立的特性分支中进行开发。不直接提交改动到master分支上也是很多工作流程的一个共同的规则。develop 是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是开发的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到
master分支中。
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。
# 功能开发
# 增加新特性
新特性的开发是基于 develop 分支的。通过下面的命令开始开发新特性：
git flow feature start [feature]
这个操作创建了一个基于 develop 的特性分支，并切换到这个分支之下。这样你就可以直接进行工作了。
# 发布新特性
如果你在合作开发一项新特性，则需要发布新特性分支到远程服务器：
git flow feature publish [feature]
这样，其他用户便可以使用这个分支进行协同开发了。
# 拉取新特性
拉取其他用户发布的新特性分支，并签出远程的更改：
git flow feature pull origin [feature]
你还可以跟踪在 origin 上的特性分支：
git flow feature track [feature]
# 完成新特性
git flow feature finish [feature]
完成开发新特性，这个动作执行下面的操作：
- 合并
[feature]分支到develop - 删除这个新特性分支
- 切换回
develop分支
# 发布版本
当你认为现在在 develop 分支的代码已经是一个成熟的 release 版本时，这意味着：
- 它包括所有新的功能和必要的修复；
- 第二、它已经被彻底的测试过了。
如果上述两点都满足，那就是时候开始生成一个新的 release 了！
# 创建新版本
使用 git flow release 命令会从 develop 分支开始创建一个 release 分支：
git flow release start [release] [base]
你可以选择提供一个 [base] 参数，即提交记录的 sha-1 hash 值，来开创建 release 分支。
这个提交记录的 sha-1 hash 值必须是 develop 分支下的。
# 发布新版本
创建 release 分支之后立即发布是非常明智的做法。
git flow release publish [release]
你可以通过以下命令签出 release 版本的远程更改：
git flow release track [release]
# 完成新版本
git flow release finish [release]
这个命令会完成如下一系列的操作：
- 首先，
git-flow会拉取远程仓库，以确保目前是最新的版本； - 然后，
release的内容会被合并到master和develop两个分支中去，这样不仅产品代码为最新的版本，而且新的功能分支也将基于最新代码； - 为便于识别和做历史参考，
release提交会被标记上这个release的名字（例如：“1.2.0”）； - 清理操作，版本分支会被删除，并且回到
develop
# 紧急修复
紧急修复通常来自这样的需求：
- 生产环境的版本处于一个不预期状态，需要立即修正；
- 有可能是需要修正
master分支上某个TAG标记的生产版本。
# 创建紧急修复
git flow hotfix start [hotfixe]
因为这是对产品代码进行修复，所以 hotfix 分支是基于 master 分支。
就像 release 一样，修复这个错误当然也会直接影响到项目的版本号！
# 完成紧急修复
在把我们的修复提交到 hotfix 分支之后，就该去完成它了：
git flow hotfix finish [hotfixe]
这个过程非常类似于发布一个 release 版本：
- 完成的改动会被合并到
master中，同样也会合并到develop分支中，这样就可以确保这个错误不会再次出现在下一个release中； - 这个
hotfix程序将被标记起来以便于参考； - 这个
hotfix分支将被删除，然后切换到develop分支上去。
# 写在最后
最后，在结束这个章节之前，我们再次强调几个重点。
首先，git-flow 并不会为 Git 扩展任何新的功能，它仅仅使用了脚本来捆绑了一系列 Git 命令来完成一些特定的工作流程。
其次，定义一个固定的工作流程会使得团队协作更加简单容易。无论是一个 “版本控制的新手” 还是 “Git 专家”，每一个人都知道如何来正确地完成某个任务。
记住，使用 git-flow 并不是必须的。当积攒了一定的使用经验后，很多团队会不再需要它了。当你能正确地理解工作流程的基本组成部分和目标的之后，你完全可以定义一个属于你自己的工作流程。