本文向您展示了如何分析GitLab Flow的十一个规则。内容简洁易懂，一定会让你眼前一亮。希望通过这篇文章的详细介绍，你能有所收获。
使用Git版本控制是在使用之前对所有版本控制方法的改进。然而，许多组织以混乱或复杂的过程告终。对于刚从其他版本控制系统转移过来的组织来说，这个问题尤为突出。
我们将列出GitLab工作流的11条规则，以帮助简化和组织工作流。这些规则的主要好处是(或者我们希望)它们可以简化过程，产生更有效、更清晰的结果。
我们认为总有改进的空间，每一个改进都是草稿。一如既往，人人都可以贡献！非常欢迎反馈和评论。
1. 使用功能分支，不直接提交到master。
例如，如果你来自SVN，你会习惯基于主干的工作流程。当使用Git时，您应该为您所做的一切创建一个分支，这样您就可以在合并之前完成代码审查。
2. 测试所有的提交，不仅仅是master上的提交。
有些人将他们的配置项设置为只测试那些合并到master中的提交。太晚了；人们应该对大师永远是绿色的测试充满信心。人们在开始开发新功能之前必须测试master是没有意义的。比如CI不是很贵，这样做是有道理的。
3. 在所有的提交上运行所有的测试(如果运行测试多于5分钟，并行运行它们)。
如果您在功能分支中工作并添加了新的提交，则在该分支中运行测试。如果测试需要很长时间，请尝试并行运行它们。应服务器的合并请求运行所有测试套件。如果您有一个用于开发的测试套件，而另一个仅用于新版本，那么设置并行测试并分别运行它们是值得的。
4. 在合并到master前执行代码评审，而非事后。
不要在周末测试所有东西。当场做，因为这样你会更容易抓到可能引起问题的东西，别人也会想办法想出解决办法。
5. 部署是自动的，基于分支或基线。
如果不想每次都部署master，可以创建一个生产分支。但是您没有理由使用脚本或登录到某个地方来手动部署。让一切自动化，或者一个特定的分支触发生产部署。
6. 基线是人为创建，而不是CI创建。
用户创建基线，配置项将基于该基线执行操作。你不应该让CI改变代码仓库。如果您需要非常详细的指标，您应该有一个列出新版本的服务器报告。
7. 依赖tags版本进行发布
如果您为项目生成了一个标签，这意味着您已经发布了一个新版本。
8.绝不以重置方式提交变更
如果您向一个公共分支提交项目变更，您不应该使用reset方法(也就是说，不要应用git rebase)。
否则将很难跟踪你对项目的改进和相应的测试结果，这实际上破坏了别人选择最有利版本的基础。
有时，我们也违反了这个规则，当我们要求投稿人使用(git merage - spansh)提交他的修订，从而提供真实的修订历史，而忽略他的本地非标准修订历史。这样，以后查找修订历史时，就很容易根据修订历史恢复版本了。但总而言之，推荐的做法是：代码应该是纯的，修改历史应该是真实的。
9. 每个人都应该从主支开始，并一直以主支为基础。
这意味着你不会从任何分支开始。您签出主分支内容，然后创建功能，提交合并请求，下一次修改将基于主分支。当你将内容合并到主分支时，你应该完成审查，不应该包括其他中间内容。
10. 先修改主支中的错误，之后发布分支。
如果你发现了一个bug，最糟糕的是你修改了刚刚发布的版本，却没有修改主分支。
为了避免这种情况，您应该总是先修改主分支，然后发布另一个版本来修复已发布版本中的错误。
11. 提交的信息中反应你修改部分的意图
你不仅要解释你做了什么，还要解释你为什么这么做。如果你解释一下为什么不使用其他方法就这样做，会更有用。
以上内容就是如何分析GitLab Flow的十一个规则。你学到什么知识或技能了吗？如果你想学习更多的技能或丰富你的知识，请关注行业信息渠道。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/151913.html