Gitflow 工作流程Gitflow 工作流程是一个Git工作流程设计，由 nvie 的 Vincent Driess

译者: 虽然 git 已经是互联网行业主流的版本控制工具, 但对于 git 新手, 或想从 svn 迁至 git 的团队而言, 一个简明合理的流程范式还是很有参考价值的.

本文译自 Bitbucket Gitfow Workflow

Gitflow 工作流程是一个Git工作流程设计，由 nvie 的 Vincent Driessen 发布并流行起来。Gitflow工作流围绕项目的版本管理定义了严格分支模型。这为管理大型项目提供了一个强大的框架。

Gitflow 非常适合具有发布周期的项目。此工作流程不会增加任何超出功能分支工作流程的新概念或命令。相反，它为不同的分支分配了非常具体的角色，并定义它们应该何时以及如何进行交互。除了feature分支外，它还使用单独的分支来准备，维护和记录版本。当然，您还可以利用功能分支工作流的所有优势：拉取请求，隔离实验和更高效的协作。

入门

Gitflow 实际上只是一个 Git 工作流的抽象概念。它规定了有哪些类型的分支以及如何将它们合并在一起。我们将在下面提到这些分支的目的。git-flow工具集是一个可安装的命令行工具。git-flow的安装过程很简单。git-flow的软件包可在多个操作系统上使用。在OSX系统上，您可以执行 brew install git-flow。在Windows上，您需要下载并安装git-flow。安装git-flow后，您可以在项目中执行 git flow init 来使用它。Git-flow 是 Git 的一层包装。该 git flow init 命令是原来 git init 命令的扩展，除了为您创建分支之外，不会更改仓库任何内容。

这个怎么运作

Develop 和 Master 分支

此工作流使用两个分支来记录项目的历史记录。master分支记录正式发布的历史, 而develop分支用作功能开发的集成分支。在使用版本号标记master的提交也很方便。

第一步是用develop分支补充主分支。一种简单的方法是让一个开发人员在本地创建一个空develop分支并将其推送到服务器：

git branch develop
git push -u origin develop

此分支将包含项目的完整历史记录，而master将包含节选的版本。其他开发人员现在应该克隆远程仓库并跟踪develop分支.

使用 git-flow 时，git flow init 会在现有repo上创建develop分支：

$ git flow init
Initialized empty Git repository in ~/project/.git/
No branches exist yet. Base branches must be created now.
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/]
Support branches? [support/]
Version tag prefix? []

$ git branch
* develop
 master

功能分支

每个新功能都应驻留在自己的分支中，可以将其推送到远程仓库以进行备份/协作。但是，feature分支使用develop作为其父分支，而不master。feature分支开发完成后，它将合并回develop分支。feature分支永远不应直接与master交互。

请注意，feature与develop分支合并是功能分支工作流的意图和目的。但是，Gitflow工作流程并不止于此。

feature分支通常是从最新的develop分支创建出来的。

创建功能分支

没有git-flow扩展：

git checkout develop
git checkout -b feature_branch

使用git-flow扩展时：

git flow feature start feature_branch

继续你的工作，像往常一样使用Git。

完成功能分支

当你完成该功能的开发工作后，下一步是合并feature_branch到develop。

没有git-flow扩展：

git checkout develop
git merge feature_branch

使用git-flow扩展：

git flow feature finish feature_branch

Release 分支

一旦develop有足够的功能可用于发布（或预定的发布日期即将来临），您就可以从develop分支分出release分支。创建此分支将启动下一个发布周期，因此在此分支不能添加任何新功能，只能做错误修复，文档生成和其他面向发布的任务。一旦准备好发布，release分支就会合并到master并标记一个版本号。此外，它还应该合并回可能已有更新的develop分支。

使用一个专有分支来准备发布可以使一个团队在完善当前版本的同时，另一个团队继续为下一个版本开发功能。它还建立了一个可明确定义的开发阶段（比如说，“本周我们正在为版本4.0做准备”，并且实际上在仓库结构中可以看到它）。

创建release分支是另一种简单的分支操作。像feature分支一样，release分支也基于develop分支。可以使用以下方法创建新release分支。

没有git-flow扩展：

git checkout develop
git checkout -b release/0.1.0

使用git-flow扩展时：

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

一旦release分支准备好发布，它会被合并到master和develop，然后release分支将被删除。合并回develop很重要，因为在新分支里需要访问到release分支的重要更新。如果您的组织强调代码审查，这将是拉取请求的理想位置。

要完成release分支，请使用以下方法：

没有git-flow扩展：

git checkout develop
git merge release/0.1.0
git checkout master
git merge release/0.1.0

或者使用git-flow扩展：

git flow release finish '0.1.0'

Hotfix 分支

维护或“hotfix”分支用于快速修补生产版本。hotfix分支很像release分支和feature分支，除了它是基于master而不是develop。它应该是唯一直接从master分出的分支。一旦修复完成，它应该合并到master和develop（或当前release分支），并且master应该用已更新的版本号标记。

通过专有的分支修复错误，使您的团队可以在不中断其余工作流程或等待下一个发布周期的情况下解决问题。您可以将hotfix分支视为直接交互与master的临时release分支。一个hotfix分支可以使用以下方法创建：

没有git-flow扩展：

git checkout master
git checkout -b hotfix_branch

使用git-flow扩展时：

$ git flow hotfix start hotfix_branch

与完成release分支类似，hotfix分支也合并到master和develop.

git checkout master
git merge hotfix_branch
git checkout develop
git merge hotfix_branch
git branch -D hotfix_branch
$ git flow hotfix finish hotfix_branch

举例

演示功能分支流程的完整示例如下。假设我们有一个带master分支的仓库。

git checkout master
git checkout -b develop
git checkout -b feature_branch
# 在 feature 分支上进行开发
git checkout develop
git merge feature_branch
git checkout master
git merge develop
git branch -d feature_branch

除了feature和release流程，还有一个hotfix例子如下：

git checkout master
git checkout -b hotfix_branch
# 开发完成后提交到 hotfix_branch
git checkout develop
git merge hotfix_branch
git checkout master
git merge hotfix_branch

摘要

在这里，我们讨论了Gitflow工作流程。Gitflow是您和您的团队可以使用的众多Git工作流程之一。

关于Gitflow的一些关键要点：

该工作流程非常适合基于发布的软件工作流程。
Gitflow提供一个专有的生产环境修复渠道。

Gitflow的总体流程：

从master创建一个develop分支
从develop创建一个release分支
从develop创建一个feature分支
当feature完成时它将合并到develop分支
当release完成时它将合并到develop和master分支
如果master检测到问题，则从master创建hotfix分支
一旦hotfix完成，它将合并到master和develop分支

接下来，了解Forking工作流程或访问我们的工作流程比较页面。