Git 工作流
Git 工作流中常见的三种分支策略：GitFlow、GitHubFlow 以及 GitLabFlow
这三种工作流程，有一个共同点：都采用”功能驱动式开发”（Feature-driven development，简称 FDD）。
它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。
Git Flow
流程
首先，项目存在 两个长期分支。
- 主分支 master：主干分支，也是正式发布版本的分支，其包含可以部署到生产环境中的代码，通常情况下只允许其他分支将代码合入，不允许向 Master 分支直接提交代码（对应生产环境）。
- 开发分支 develop：开发分支，用来集成测试最新合入的开发成果，包含要发布到下一个 Release 的代码（对应开发环境）。
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的分布版；后者用于日常开发，存放最新的开发版。
其次，项目存在 三种短期分支。
- 功能分支（feature branch）：特性分支，通常从 Develop 分支拉出，每个新特性的开发对应一个特性分支，用于开发人员提交代码并进行自测。自测完成后，会将 Feature 分支的代码合并至 Develop 分支，进入下一个 Release。
- 补丁分支（hotfix branch）：发布分支，发布新版本时，基于 Develop 分支创建，发布完成后，合并到 Master 和 Develop 分支（对应集成测试环境）。
- 预发分支（release branch）：热修复分支，生产环境发现新 Bug 时创建的临时分支，问题验证通过后，合并到 Master 和 Develop 分支。
一旦完成开发，它们就会被合并进 develop 或 master，然后被删除。
总结
Git flow 的优点是清晰可控，缺点是相对复杂，需要同时维护两个长期分支。大多数工具都将 master 当作默认分支，可是开发是在 develop 分支进行的，这导致经常要切换分支，非常烦人。
更大问题在于，这个模式是基于”版本发布”的，目标是一段时间以后产出一个新版本。但是，很多网站项目是”持续发布”，代码一有变动，就部署一次。这时，master 分支和 develop 分支的差别不大，没必要维护两个长期分支。
Github Flow
流程
Github flow 是 Git flow 的简化版，专门配合”持续发布”。它是 Github.com 使用的工作流程。
它只有一个长期分支，就是 master，因此用起来非常简单。官方推荐的流程如下。
- 第一步：根据需求，从 master 拉出新分支，不区分功能分支或补丁分支。
- 第二步：新分支开发完成后，或者需要讨论的时候，就向 master 发起一个 pull request（简称 PR）。
- 第三步：Pull Request 既是一个通知，让别人注意到你的请求，又是一种对话机制，大家一起评审和讨论你的代码。对话过程中，你还可以不断提交代码。
- 第四步：你的 Pull Request 被接受，合并进 master，重新部署后，原来你拉出来的那个分支就被删除。（先部署再合并也可。）
很多人可能会问，提交代码通常是 commit 或者 push，拉取代码才是 pull，为什么 GitHubFlow 中提交代码提出的是“Pull Request”。因为在 GitHubFlow 中，PR 是通知其他人员到你的代码库去拉取代码至本地，然后由他们进行最终的提交，所以用“pull”而非“push”。
总结
Github flow 的最大优点就是简单，对于”持续发布”的产品，可以说是最合适的流程。
问题在于它的假设：master 分支的更新与产品的发布是一致的。也就是说，master 分支的最新代码，默认就是当前的线上代码。
可是，有些时候并非如此，代码合并进入 master 分支，并不代表它就能立刻发布。比如，苹果商店的 APP 提交审核以后，等一段时间才能上架。这时，如果还有新的代码提交，master 分支就会与刚发布的版本不一致。另一个例子是，有些公司有发布窗口，只有指定时间才能发布，这也会导致线上版本落后于 master 分支。
上面这种情况，只有 master 一个主分支就不够用了。通常，你不得不在 master 分支以外，另外新建一个 production 分支跟踪线上版本。
Gitlab Flow
流程
Gitlab flow 是 Git flow 与 Github flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。它是 Gitlab.com 推荐的做法。
上游优先
Gitlab flow 的最大原则叫做”上游优先”（upsteam first），即只存在一个主分支 master，它是所有其他分支的”上游”。只有上游分支采纳的代码变化，才能应用到其他分支。
Chromium 项目就是一个例子，它明确规定，上游分支依次为：
- Linus Torvalds 的分支
- 子系统（比如 netdev）的分支
- 设备厂商（比如三星）的分支
Gitlab flow 分成两种情况，适应不同的开发流程。
持续发布
对于”持续发布”的项目，它建议在 master 分支以外，再建立不同的环境分支。比如，”开发环境”的分支是 master，”预发环境”的分支是 pre-production，”生产环境”的分支是 production。
开发分支是预发分支的”上游”，预发分支又是生产分支的”上游”。代码的变化，必须由”上游”向”下游”发展。比如，生产环境出现了 bug，这时就要新建一个功能分支，先把它合并到 master，确认没有问题，再 cherry-pick 到 pre-production，这一步也没有问题，才进入 production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
版本发布
对于”版本发布”的项目，建议的做法是每一个稳定版本，都要从 master 分支拉出一个分支，比如 2-3-stable、2-4-stable 等等。
以后，只有修补 bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
一些技巧
Protected branch
master 分支应该受到保护，不是每个人都可以修改这个分支，以及拥有审批 Pull Request 的权力。
Github 和 Gitlab 都提供”保护分支”（Protected branch）这个功能。
Issue
Issue 用于 Bug 追踪和需求管理。建议先新建 Issue，再新建对应的功能分支。功能分支总是为了解决一个或多个 Issue。
功能分支的名称，可以与 issue 的名字保持一致，并且以 issue 的编号起首，比如”15-require-a-password-to-change-it”。
开发完成后，在提交说明里面，可以写上”fixes #14”或者”closes #67”。Github 规定，只要 commit message 里面有下面这些 动词 + 编号，就会关闭对应的 issue。
close、closes、closed、fix、fixes、fixed、resolve、resolves、resolved
这种方式还可以一次关闭多个 issue，或者关闭其他代码库的 issue，格式是 username/repository#issue_number。
Pull Request 被接受以后，issue 关闭，原始分支就应该删除。如果以后该 issue 重新打开，新分支可以复用原来的名字。
Merge 节点
Git 有两种合并：一种是”直进式合并”（fast forward），不生成单独的合并节点；另一种是”非直进式合并”（none fast-forword），会生成单独节点。
前者不利于保持 commit 信息的清晰，也不利于以后的回滚，建议总是采用后者（即使用—no-ff 参数）。只要发生合并，就要有一个单独的合并节点。
Squash 多个 commit
为了便于他人阅读你的提交，也便于 cherry-pick 或撤销代码变化，在发起 Pull Request 之前，应该把多个 commit 合并成一个。（前提是，该分支只有你一个人开发，且没有跟 master 合并过。）
这可以采用 rebase 命令附带的 squash 操作，具体方法请参考 《Git 使用规范流程》。