使用 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 到其他补丁发布分支（比如 production 分支）。

11. 提交信息（commit message）应体现意图

不仅要说清楚做了什么，还要说明为什么这么做。
如果解释一下为什么用这种方式，而不是其他方式，则会更加有用。

更多内容请移步 GitLab Flow 文档。

原文：https://about.gitlab.com/2016/07/27/the-11-rules-of-gitlab-flow/