介绍Git工作流指南：Gitflow工作流

本节介绍的Gitflow工作流由Vincent Driessen于nvie提出。Gitflow工作流定义了一套围绕项目发布的严格分支模型，虽相较于功能分支工作流更为复杂，但为管理大型项目提供了一个健壮的框架。

Gitflow工作流概述

Gitflow工作流并未引入超出功能分支工作流的概念和命令，而是为不同的分支赋予明确的角色，并定义了分支之间交互的方式和时机。除了使用功能分支，在发布准备、维护和记录发布过程中也使用各自独立的分支。同时，你可以充分利用功能分支工作流的所有优势，如Pull Requests、隔离实验性开发以及实现更高效的协作。

工作方式

Gitflow工作流依然以中央仓库作为所有开发者的交互中心。和其他工作流一样，开发者在本地进行工作，并将分支推送到中央仓库。

历史分支

与仅使用一个master分支不同，Gitflow工作流使用两个分支来记录项目历史。master分支存储正式发布的历史，而develop分支作为功能的集成分支。这样便于为master分支上的所有提交分配版本号。后续的相关问题也主要围绕这两个分支的区别展开。

功能分支

每个新功能都位于一个独立的分支，这样可以将其推送到中央仓库进行备份和协作。功能分支并非从master分支创建，而是以develop分支作为父分支。当新功能开发完成后，将其合并回develop分支。新功能的提交不应直接与master分支交互。从各种意义和用途来看，功能分支与develop分支的组合使用方式与功能分支工作流一致，但Gitflow工作流的功能不止于此。

发布分支

当develop分支上积累了足够的功能可以进行一次发布（或接近既定的发布日期）时，从develop分支派生一个发布分支。新创建的分支用于启动发布周期，从此时起，新功能不应再添加到该分支，该分支仅用于Bug修复、文档生成和其他面向发布的任务。一旦完成对外发布的所有工作，将发布分支合并到master分支，并分配版本号并打好标签（Tag）。此外，自创建发布分支以来所做的修改也需要合并回develop分支。

使用专门的发布准备分支，使得一个团队可以专注于完善当前的发布版本，而另一个团队可以继续开发下一个版本的功能。这也定义了良好的开发阶段（例如，可以明确表示“本周我们要准备发布4.0版本”，并且可以在仓库的目录结构中直观看到）。

常用的分支约定如下：

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

维护分支

维护分支（或称为热修复分支，hotfix）用于快速为产品发布版本打补丁，它是唯一可以直接从master分支派生出来的分支。修复完成后，应立即将修改合并回master分支和develop分支（当前的发布分支），并为master分支使用新的版本号打好标签。

使用专门的分支进行Bug修复，使团队能够在不中断其他工作或等待下一个发布周期的情况下处理问题。可以将维护分支视为直接在master分支上进行的临时发布。

示例

以下示例展示了如何使用此工作流管理单个发布周期。假设你已经创建了一个中央仓库。

创建开发分支

第一步是为master分支配套一个develop分支。可以在本地创建一个空的develop分支，并将其推送到服务器：

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

此时，每个开发者都拥有这些历史分支的本地副本。

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

在这个示例中，小红和小明开始各自的功能开发。他们需要为各自的功能创建相应的分支，新分支应基于develop分支，而非master分支：

git checkout -b some-feature develop

他们按照常规方式向各自的功能分支添加提交：编辑、暂存、提交：

git status
git add <file>
git commit -m "Commit message"

小红完成功能开发

添加提交后，小红认为她的功能开发完成。如果团队使用Pull Requests，此时可以发起一个合并到develop分支的请求。否则，她可以直接将功能合并到本地的develop分支，然后推送到中央仓库：

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

这个分支用于清理发布、执行所有测试、更新文档和其他为下一次发布做准备的操作，类似于一个专门用于改进发布的功能分支。

一旦小红创建了这个分支并将其推送到中央仓库，该发布就进入功能冻结状态。任何不在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分支时，都应该打好标签以便跟踪：

git tag -a 0.1 -m "Initial public release" master
git push --tags

Git提供了各种钩子（hook），即仓库中发生特定事件时触发执行的脚本。可以配置一个钩子，在将修改推送到中央仓库的master分支时，自动构建对外发布。

最终用户发现Bug

对外发布后，小红返回与小明一起进行下一次发布的新功能开发，直到有最终用户报告当前版本存在一个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