Git Flow的问题

有时候，你可能会拥有太多的好东西。Git flow当然是这样，这是一个著名的软件开发工作流，它提供了几个选项，但可能会让用户陷入困境。

我们开发GitLab Flow作为解决方案，以消除混乱的复杂性并简化开发过程。GitLab Flow为Git工作流程带来了问题跟踪，简化了流程并消除了混乱。

要理解GitLab Flow是如何工作的，首先看看它试图解决的问题是很有帮助的。在Git flow中，有两个主要的痛点，这两个痛点都涉及不必要的分支切换。

Git flow强制开发人员使用开发分支，而不是主分支。因为大多数工具默认使用主服务器，所以涉及到大量的分支切换。另一个令人沮丧的方面是Hotfix和Release分支，这对大多数组织来说是矫枉过正的，在实践持续交付的公司中是完全不必要的。

GitLab Flow将功能驱动开发和功能分支与问题跟踪相结合。GitLab Flow将Git工作流与问题跟踪系统集成在一起，提供了一种简单、透明和有效的方式来使用Git。

GitLab Flow是一种使代码和问题跟踪器之间的关系更加透明的方法。对代码库的每次更改都始于问题跟踪系统中的一个问题。当您完成编码或想要讨论代码时，可以打开合并请求。当代码准备就绪时，审阅者将把分支合并到主分支中，创建一个合并提交，使此事件在将来很容易看到。使用GitLab flow，团队可以通过将主代码合并到生产分支来部署新版本的代码，从而使他们能够快速识别生产中的代码。在此工作流中，仅向下提交流，以确保所有内容都在所有环境中进行测试。

GitLab流程是一种从创意阶段转移到生产阶段的方式，同时让每个人都了解情况，提高工作效率。我们确定了软件投入生产所必须经历的开发过程的10个关键阶段。GitLab Flow可以轻松地说明所有问题，同时继续提供对开发生命周期的全面了解。

一般而言，GitLab流程分为三个主要区域：特性分支、生产分支和发布分支。

功能分支是重要的开发工作发生的地方。开发人员创建一个特性或错误修复分支，并在那里完成所有工作，而不是在主分支上。一旦工作完成，开发人员就会创建一个合并请求，将工作合并到主分支中。

生产分支本质上是一个整体-单个长期运行的生产发布分支，而不是单个分支。可以为每个可部署版本创建一个标记，以便轻松跟踪这些细节。

如果您向客户发布软件，最后一个部分，即发布分支是关键。对于每个新版本，您都会从master创建一个稳定的分支，并决定一个标记。如果您需要发布补丁，请确保首先精挑细选关键的bug修复，并且不要将它们直接提交给稳定分支。

想要最大限度地利用GitLab流程吗？我们的首席执行官Sid Sijbrdij提出了团队应该始终遵守的11条规则，以实现最高效率。这个博客整体上值得一读，但这里有几条规则可以及时提醒您测试的重要性，即使在CI环境中也是如此：

测试所有提交：不要等到所有内容都合并到主服务器中才进行测试。测试在此过程中进行提交，以便在流程的早期发现问题。

并对所有提交运行所有测试，即使您必须并行运行测试。

代码评审>；合并到MASTER中。希德写道：为什么要等呢？不要在周末测试所有东西。当场做，因为你更有可能抓到可能引起问题的东西，其他人也会努力想出解决办法。