Git 分支管理 git-flow

git-flow

git-flow 应该是目前流传最广的 Git 分支管理实践。git-flow 围绕的核心概念是版本发布（release）。因此 git-flow 适用于有较长版本发布周期的项目。虽然目前推崇的做法是持续集成和随时发布。有的项目甚至可以一天发布很多次。随时发布对于 SaaS 服务类的项目来说是很适合的。不过仍然有很大数量的项目的发布周期是几个星期甚至几个月。较长的发布周期可能是由于非技术相关的因素造成的，比如人员限制、管理层决策和市场营销策略等。

git-flow 流程中包含 5 类分支，分别是 master、develop、新功能分支（feature）、发布分支（release）和 hotfix。这些分支的作用和生命周期各不相同。master 分支中包含的是可以部署到生产环境中的代码，这一点和 GitHub flow 是相同的。develop 分支中包含的是下个版本需要发布的内容。从某种意义上来说，develop 是一个进行代码集成的分支。当 develop 分支集成了足够的新功能和 bug 修复代码之后，通过一个发布流程来完成新版本的发布。发布完成之后，develop 分支的代码会被合并到 master 分支中。

其余三类分支的描述如表 1所示。这三类分支只在需要时从 develop 或 master 分支创建。在完成之后合并到 develop 或 master 分支。合并完成之后该分支被删除。这几类分支的名称应该遵循一定的命名规范，以方便开发人员识别。

表 1. git-flow 分支类型

分支类型	命名规范	创建自	合并到	说明
feature	feature/*	develop	develop	新功能
release	release/*	develop	develop 和 master	一次新版本的发布
hotfix	hotfix/*	master	develop 和 master	生产环境中发现的紧急 bug 的修复

对于开发过程中的不同任务，需要在对应的分支上进行工作并正确地进行合并。每个任务开始前需要按照指定的步骤完成分支的创建。例如当需要开发一个新的功能时，基本的流程如下：

• 从 develop 分支创建一个新的 feature 分支，如 feature/my-awesome-feature。
• 在该 feature 分支上进行开发，提交代码，push 到远端仓库。
• 当代码完成之后，合并到 develop 分支并删除当前 feature 分支。

在进行版本发布和 hotfix 时也有类似的流程。当需要发布新版本时，采用的是如下的流程：

• 从 develop 分支创建一个新的 release 分支，如 release/1.4。
• 把 release 分支部署到持续集成服务器上进行测试。测试包括自动化集成测试和手动的用户接受测试。
• 对于测试中发现的问题，直接在 release 分支上提交修改。完成修改之后再次部署和测试。
• 当 release 分支中的代码通过测试之后，把 release 分支合并到 develop 和 master 分支，并在 master 分支上添加相应的 tag。

因为 git-flow 相关的流程比较繁琐和难以记忆，在实践中一般使用辅助脚本来完成相关的工作。比如同样的开发新功能的任务，可以使用 git flow feature start my-awesome-feature 来完成新分支的创建，使用 git flow feature finish my-awesome-feature 来结束 feature 分支。辅助脚本会完成正确的分支创建、切换和合并等工作。

参考：
https://www.ibm.com/developerworks/cn/java/j-lo-git-mange/index.html