使用Git版本控制是对所有版本控制方法在使用前的改进。然而，许多组织最终的流程过于混乱或过于复杂。对于刚刚从其他版本控制系统过渡的组织来说，这个问题尤为严重。在本文中，我们将列出GitLab工作流的11条规则，以帮助简化和组织工作流。这些规则的主要好处是（或者我们希望是）它简化了过程并产生更有效和更清晰的结果。我们认为总有改进的余地，每一次改进都是一个草稿。一如既往，每个人都可以做出贡献！非常欢迎反馈和评论。1.使用功能分支，不直接提交给master。例如，如果您来自SVN，您将习惯基于主干的工作流程。使用Git时，你应该为你所做的一切创建一个分支，这样你就可以进行预合并代码审查。2.测试所有提交，而不仅仅是master上的提交。有些人将他们的CI设置为仅测试合并到master中的提交。太晚了;人们应该对测试master总是绿色的充满信心。人们在开始开发新功能之前必须测试master是没有意义的，例如，CI不是很昂贵，所以这样做是有意义的。3.对所有提交运行所有测试（如果运行测试花费的时间超过5分钟，请并行运行它们）。如果您正在处理功能分支并添加新提交，请在该分支上运行测试。如果测试需要很长时间，请尝试并行运行它们。服务器端的合并请求运行所有测试套件。如果您有一个测试套件用于开发而另一个测试套件仅用于新版本，那么设置并行测试并分别运行它们是值得的。4.在合并到master之前执行代码审查，而不是之后。不要在周末测试所有内容。当场进行，因为这样您会更容易发现可能导致问题的原因，而其他人会努力想出解决方案。5.部署是自动的，基于分支或基线。如果不想每次都部署master，可以创建一个production分支。但是您没有理由使用脚本或登录到某个地方来手动部署。自动化一切，或特定分支触发生产部署。6.基线是人为创建的，而不是CI创建的。用户创建基线，CI将根据该基线执行操作。您不应该让CI更改代码存储库。如果您需要非常详细的指标，您应该有一个列出新版本的服务器报告。7.依赖tags版本发布如果你为你的项目生成tags，就意味着你已经发布了一个新版本。8.切勿通过重置提交更改如果您将项目的更改提交到公共分支，则不应使用重置（即不要应用gitrebase），否则将很难跟踪您在项目上的进度。改进和相应的测试结果，这样做实际上破坏了其他人选择最喜欢的版本的基础。当我们要求贡献者使用(gitmerge--spansh)提交他的更改以提供真实的更改历史时，我们有时也会违反此准则，而忽略他的本地非规范更改历史。这样做之后，在查看修改历史时，很容易根据修改历史恢复版本。但总而言之，推荐的做法是：代码要纯净，修改历史要真实。9、大家要从主干做起，永远建在主干上。这意味着您不从任何分支开始。你签出主分支的内容，然后创建你的特性，提交你的合并请求，接下来的修改还是基于主分支。当你合并内容到主分支时，你应该完成审查，不应该包括其他中间内容。10.先修改主分支的错误，再发布分支。如果你发现了一个bug，可能发生的最糟糕的事情就是你修改了刚刚发布的版本而不修改主分支。为避免这种情况，您应该始终先对主分支进行更改，然后发布另一个版本以修复已发布版本中的错误。11、在提交的信息中反映出修改部分的意向。你不仅应该解释你做了什么，还应该解释你为什么这样做。如果您解释为什么这样做而不是使用其他方式，那将会更有帮助。
