使用 Git 进行版本管理，是对 Git 之前所有方法的改进。然而，很多组织最终会出现凌乱的工作流程，或过于复杂的工作流程。这问题对于从另一版本控制系统转换过来的组织来说尤为突出。
本文中，我们为 GitLab 工作流程制定了11条规则，以帮助简化和清晰。规则的主要好处（或者说我们希望的好处）是它简化过程，并产生更加有效和更清晰的结果。
总是存在改善空间，一切均为草稿。一如既往，人人皆可贡献！非常欢迎提出反馈意见！
1. 使用功能分支，不直接提交（commit）到 master 分支。 如果你从 SVN 转过来，举例来说，你会习惯于基于主干（trunk）的工作流程。而使用 Git 时，任何正在进行的操作，都应为之创建一个分支（branch），以便最终在合并（merge）之前进行代码审查（code review）。
2. 测试所有的提交，而不仅仅只在 master 分支上。
有些人将 CI 系统设置为只测试合并到 master 分支的东西。这太迟了！总是拥有绿色的 master 测试（译者注：绿色在 CI 里通常意味着测试通过，而红色意味着测试失败），人们会觉得有信心。例如，在开始开发新功能之前，人们不得不测试 master 分支那是没有意义和荒谬的。CI 并不昂贵，所以这样做是最好的。
3. 在所有的提交上，运行所有的测试（如果你的测试时间长于 5 分钟则让它们并行）。
如果您正工作在一个功能分支并添加新提交（commit），请随之运行测试。如果测试需要很长时间，请尝试并行运行。合并请求（merge requests）时，在服务器端来执行此操作以运行完整的测试套件。如果你有一个用于开发的测试套件，而另一个测试套件你只为新版本运行；那么设置并行测试并运行全部测试套件是值得的。
4. 在合并到 master 之前执行代码审查，而不是事后审查。
不要在一周结束时测试一切。当场就搞！这样你更有可能抓住可能导致问题的东西，而其他人也会努力提出解决方案。
5. 部署是自动的，并基于分支或标签（tag）。
如果您不想每次都部署 master 分支，那么你可以创建一个 production 分支；但你没理由用脚本（script）或登录到某个地方手动操作。自动化一切，或以特定分支来触发生产部署。
6. 标签（tag）是由用户设置的，而不是由 CI 创建。
应由用户来打标签（tag），并且基于此，CI 将执行一个动作。不应让 CI 去更改代码库。如果你需要非常详细的指标，你应该有一个服务器报告来详细说明新版本。
7. 发布（release）是基于标签（tag）的。
如果你打了 tag，则意味着创建了一个新版本。
8. 永远不对已推送的提交（pushed commits）进行变基（rebase）。
当你推送（push）到公共分支后，你就不该对其变基，因为这样会很难跟进你正在改进的内容，很难跟进测试结果是什么，而且它打破了 cherry-picking。有时我们在审查流程的后期要求代码贡献者合并及变基（git merge --squash），以使一些东西容易还原时，我们也会违背这一规则。但一般而言，准则是：代码应干净，修改历史应真实。
9. 每个人都从 master 分支开始工作，目标也是 master 分支。
这意味着没有任何长期分支。你可以检出 master 分支，构建功能，创建合并请求，并再次指向到 master 分支。在合并之前，应该进行完整的代码审查，而不应在代码审查和合并间存在任何中间阶段。
10. 在 master 分支中修正错误，其次再到发布分支。
如果你发现 bug，最糟的事莫过于你在刚发布的版本里修复了它，而未在 master 分支修复。为避免这种情况，应总是向前修复（fix forward）。在 master 中修复，然后 cherry-pick 到其他补丁发布分支。
11. 提交信息（commit message）应体现意图。
不仅要说明你做了什么，还应说明为什么这么做。如果解释一下为什么这么做，而不是用其他方式，这会更加有用。
更多内容请移步 GitLab Flow 文档。
原文：https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/
