Git 分支工作流介绍

Git 是目前最流行的代码管理工具，团队一般为了规范开发，保持良好的代码提交记录以及维护 Git 分支结构清晰，方便后续维护等，都会定制一套团队内部比较规范的 Git 工作流。本期主要介绍最为常见和流行的三种Git分支工作流。

GitFlow

GitFlow 是最早诞生，并且得到广泛应用的一种工作流程。GitFlow 通常包含五种类型的分支，分别为master、develop、feature、release、hotfix。

• master：主干分支，也是正式发布版本的分支，每次发布版本都需要打上相应的 tag，其包含可以部署到生产环境中的代码，通常情况下只允许其他分支将代码合入，不允许直接向 master 分支直接提交代码 (master 对应着生产环境)。

• develop：开发分支，在开发初期，由团队负责人从 master 签出，用来集成测试最新合入的开发成果，包含要发布到下一个 Release 的代码（对应开发环境）。

• feature：特性分支，通常从 Develop 分支签出，每个新特性的开发对应一个特性分支，用于开发人员提交代码并进行自测。自测完成后，会将 Feature 分支的代码合并至 Develop 分支，进入下一个Release 环节。

• release：预发布分支，发布新版本时，基于 Develop 分支创建，发布完成后，需要将此分支合并到 Master 和 Develop 分支（对应集成测试环境）。

• hotfix：热修复分支，生产环境发现新 Bug 时创建的临时分支，问题验证通过后，合并到 Master 和 Develop 分支。

develop分支包含项目完整的历史记录，而master分支将包含简化版本。团队成员在克隆中央存储库后，应基于develop创建跟踪分支，进行新功能开发。

GitFlow的优点和缺点？

• 优点：流程清晰可控。

• 缺点：管理相对复杂，需要同时维护两个长期分支。同时不适合持续发布，目标产物通常是一段时间后产出一个新版本，是基于版本发布。

开发分支（Develop）

Develop 分支由团队负责人从 Master 创建。首次创建时，由团队负责人构建项目结构，推送至远端。通常在该分支上进行新特性的合并、签出予发布分支、合并hotfix分支等操作。

特性分支（Feature）

新特性分支基于 Develop 分支创建，每个新功能都应该驻留在其自己的分支中，我们可以将其推送到中央存储库进行协作或者备份。

在新功能开发完成后，需要将其合并到 Develop 分支中，同时删除本地与远端的feature分支。

预发布分支（Release）

一旦 Develop 分支获得了足够的发布功能，或者临近预定的发布日期，就需要基于 Develop 分支创建Release 分支。

创建此分支意味着将开始下一个发行周期，此刻 Release 分支不能添加任何新功能（除了错误修复、文档完善等），一旦准备发布，Release 分支将合并到 Master 分支并用版本号标记。另外，还要将其合并回 Develop 分支。待发版成功后，删除 Release 分支。

使用专门的分支进行版本发布可以让我们在新版本发布的同时，其他团队成员可以继续为下个版本开发新功能，而不影响此次发布。

补丁分支（hotfix）

维护 hotfix 分支用于快速修补生产版本出现的 bug。hotfix 分支是唯一一个从 Master 分支上创建的分支。

待修复程序完成后，应该将其合并到 Master 和 Develop 或者当前 Release 分支中，随后删除 hotfix 分支，并应使用更新的版本号标记 Master 分支。

拥用有专门的错误修复分支，可以保障团队可以在不中断其余工作流程的情况下，对线上的版本进行错误修复。

Github Flow

GitHub flow 是 Git Flow 的简化版，它是 github.com 使用的工作流程。它只有一个长期分支(master)，相对于 GitFlow 用起来相对比较简单。GitHubFlow 假设每次合并一个特性分支时都可以部署到生产环境，虽然这在某些情况下是不可能的。

它只有一个长期分支master：

• 第一步：根据需求，从 master 拉出新分支，不区分功能分支或补丁分支。

• 第二步：新分支开发完成后，或者需要讨论的时候，就像 master 分支发起一个pull request(简称PR)。

• 第三步：Pull Request既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码，对话过程中，你还可以不断提交代码。

• 第四步：你的Pull Request被接受，合并进master，重新部署后，原来你拉出来的那个分支就被删除。

GitHub Flow的优点和缺点？

• 优点：非常适合持续发布的产品，使用流程简单，仅有一个主干分支。Master 分支的最新代码，默认就是线上代码。

• 缺点：master 既包含生产环境，又包含开发环境，比较混乱。有些时候，代码合并进入 Master 分支，并不代表就能立刻发布，你不能控制发布的时间。例如，iOS 应用程序通过App Store验证后才发布。这是，如果后面还有新的代码合并到 Master，导致与刚刚发布的版本不一致。在这些情况下，需要额外创建一个 production 分支跟踪线上版本。如果想要查看生产环境代码，可切换至生产分支。

Gitlab Flow

Gitlab Flow 是 Git Flow 与 Github Flow 的结合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一分支的简单和便利，是 gitlab.com 推荐的做法。

上游优先

Gitlab Flow 的最大原则叫做“上游优先”，指存在一个主分支，他是所有其他分支的上游，只有上游分支采纳的代码变化，才能应用到其他分支。

持续发布

对于持续发布的项目，建议在 Master 之外，创建不同环境的分支，比如开发环境是 Master，预发布分支是pre-production，生产环境是production。

开发分支是语发布分支的上游，予发布分支是生产分支的上游。代码变化，必须由上游向下游发展。

版本发布

对于版本发布的项目，建议的做法是每一个稳定的版本，都要从 Master 分支上拉出一个分支，比如1.0.3-stable等等。

发布版本后，只有向该分支添加严重的错误修复，首先将错误修复合并到 Master 分支，然后将其合并到 stable 分支，并且此时要更新小版本号码。