GitLab Flow 的 11 条规则


使用 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/ ... flow/

0 个评论

要回复文章请先登录注册