欢迎来到
GitLab flow
定义
编辑
GitLab Flow 是 Git Flow 的一个更简单的替代品，它将特性驱动开发和特性分支与问题跟踪相结合。使用 GitLab Flow，所有的功能和修复都会进入main主分支，同时启用production（生产）和stable（稳定）分支。GitLab Flow 包括一套最佳实践和指南，以确保软件开发团队遵循一个顺利的流程来协作发布功能。
GitLab Flow 是 Git Flow 与 GitHub Flow 的综合。它吸取了两者的优点，既有适应不同开发环境的弹性，又有单一主分支的简单和便利。
实践出处
编辑
为什么
编辑
Git 支持很多种分支策略和工作流（workflow）。正由于此，许多组织用户最终所使用的工作流太复杂，定义不清晰，或者缺少了问题追踪系统。因此提出了 GitLab 工作流，作为一个清晰明了的一套最佳实践。它结合了特性驱动开发和特性分支，并且包含了问题追踪。
很多初次接触 Git 的组织用户不了解 Git 的使用惯例，因而他们的代码仓库很快会变得杂乱无章。其中最大的问题是，很多持续维护的分支都只包含了部分更改。人们会很难搞清楚，哪个分支包含了最新的代码，或者哪个分支会部署到生产。 很多情况下，对于这个问题人们的反应是采用标准化的模式，例如 Git Flow 和 GitHub Flow。
GitLab 认为这些方法仍有改进空间，所以产出了一套实践，称之为 GitLab Flow。
何时使用
编辑
想简化 Git Flow 和 GitHub Flow 流程时。
如何使用
编辑
1. 上游优先
Gitlab Flow 的最大原则叫做"上游优先"（upsteam first），即只存在一个主分支main，它是所有其他分支的"上游"。只有上游分支采纳的代码变化，才能应用到其他分支。
2. 持续发布
Gitlab Flow 分成两种情况，适应不同的开发流程。
对于"持续发布"的项目，它建议在main分支以外，再建立不同的环境分支。比如，"开发环境"的分支是main，"预发环境"的分支是pre-production，"生产环境"的分支是production。
开发分支是预发分支的"上游"，预发分支又是生产分支的"上游"。代码的变化，必须由"上游"向"下游"发展。比如，生产环境出现了bug，这时就要新建一个功能分支，先把它合并到main，确认没有问题，再cherry-pick到pre-production，这一步也没有问题，才进入production。
只有紧急情况，才允许跳过上游，直接合并到下游分支。
3. 版本发布
对于"版本发布"的项目，建议的做法是每一个稳定版本，都要从main分支拉出一个分支，比如2-3-stable、2-4-stable等等。
以后，只有修补bug，才允许将代码合并到这些分支，并且此时要更新小版本号。
参考资料
编辑
我们非常重视知识产权，我们在非常努力地寻找最初的出处来源并注明出处。但因为互联网信息浩瀚，难免会有疏漏。如果您觉得有侵犯您的权益，请联系我们。
导出GitLab flow.pdf
导出GitLab flow.docx
导出GitLab flow.pptx分享
