Git 流(Git Flow)
最知名的工作流程。它由Vincent Driessen于2010年创建，它基于两个无限生命的主要分支：
- master：此分支包含生产代码。所有开发代码都会在某个时候合并到master中。
- develop：此分支包含预生产代码。功能完成后，它们将合并到开发中。
在开发周期中，使用了各种支持分支：
在开发周期中，使用了各种支持分支：
- feature：功能分支用于为即将发布的版本开发新功能。可以从develop中分支出来，必须合并为develop。
- hotfix：修补程序分支是必需的，以便立即修复master分支的不良状态。可能会从master分支出来，并且必须要合并进master和develop分支。
- release：版本分支支持新产品版本的准备。它们允许修复许多小错误，并准备发布元数据。可能会从develop中分支出来，并且必须合并要合并进master和develop分支。
优点：
- 确保项目生命周期中任何给定时刻的分支状态干净
- 分支的命名遵循系统的模式，使其更易于理解
- 它具有对大多数常用git工具的扩展和支持
- 当生产中需要多个版本时是理想选择
缺点：
- Git历史记录变得不可读
- master/develop 分离被认为是多余的，这使得持续交付和持续集成更加困难当需要在生产中维护单个版本时，不建议使用
Github 流(Github Flow)
GitHub 流是一个轻量级的工作流程。它由GitHub在2011年创建，并遵循以下6条原则：
- master分支中的任何内容都是可部署的
- 要处理新内容，请从master创建一个分支，并指定一个描述性名称（例如：new-oauth2-scopes）
- 本地提交到该分支，并定期将您的工作推送到服务器上的同一命名分支
- 当您需要反馈或帮助时，或者您认为分支可以合并时，请打开拉取请求
- 在其他人查看并签署了该功能后，您可以将其合并到主功能中
合并并推送到主服务器后，您可以并且应该立即部署
优点：
- 它对于持续交付和持续集成非常友好
- Git 流的更简单替代
- 当需要在生产中维护单个版本时，它是理想的选择
缺点：
- 生产代码最容易变得不稳定
- 需要发布计划时还不够
- 它无法解决有关部署，环境，发行版和问题的任何问题
- 当需要在生产中使用多个版本时，不建议使用
Gitlab 流(Gitlab Flow)
GitLab 流是由GitLab在2014年创建的工作流。它将功能驱动的开发和可以问题跟踪的功能分支结合在一起。 GitLab流与GitHub流之间的最大区别是GitLab 流中具有的环境分支（例如，staging和production），因为每次合并功能分支（例如SaaS应用程序和移动应用）时，都会有一个项目无法部署到生产中。GitLab 流基于一下11条规则：
- 使用功能分支，不对母版直接提交
- 测试所有提交，不仅是在master分支上的提交
- 对所有提交运行所有测试（如果您的测试运行超过5分钟，则可以并行运行它们）。
- 在合并到master分支之前（而不是之后）执行代码审查。
- 部署是自动的，基于分支或标签。
- 标签是由用户而不是CI设置的。
- 版本基于标签。
- 推送的提交永远不会重新建立基础。
- 每个人都从master分支开始，并以master分支为目标。
- 首先修复master分支中的错误，然后修复发布分支。
- 提交消息反映了意图
优点：
- 它定义了如何进行持续集成和持续交付
- git历史记录将更简洁，更混乱且更易读
- 当需要在生产中使用单个版本时，它是理想的选择
缺点：
- 当需要在生产中维护多个版本时，它可能会像Git流一样变得复杂
单流 (One Flow)
Adam Ruka在2015年撰写的GitFlow文章中建议的替代方案。使用OneFlow需满足的主要条件是，每个新的生产版本均基于先前的版本。 One Flow和Git Flow之间最大的区别在于它没有开发分支。
优点
- git历史记录将更简洁，更混乱且更易读
- 根据团队决定灵活
- 当需要在生产中使用单个版本时，它是理想的选择
缺点
- 对于具有持续交付或持续部署的项目，建议不要使用它
- 功能分支使CI更加困难
- 当需要在生产中维护单个版本时，不建议使用