GitLab Flow 的 11 条规则

purplesnake 发布于5月前 阅读3552次
0 条评论

使用 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 文档。

原文:

查看原文: GitLab Flow 的 11 条规则

需要 登录 后回复方可回复, 如果你还没有账号你可以 注册 一个帐号。