9年前在公司内网部署了Gerrit2，一直使用至今。是时候重现看看Gerrit2和GitLab了...

Gerrit 与 GitLab

Gerrit在特定领域（如Android开源项目）和特定组织中仍然很受欢迎，

GitLab的用户群更加广泛。GitLab提供了更全面的功能和工具。

Gerrit

• Gerrit Code Review | Gerrit Code Review

Gerrit： Gerrit是由Google的一位工程师Shawn Pearce于2008年创建的。最初，Gerrit是为了解决Android开源项目的代码审查需求而开发的。Gerrit提供了一种基于Web的代码审查工作流，允许开发人员在代码变更之前进行同行评审和讨论。它的目标是提供一个高效的代码审核平台，以促进团队合作和代码质量的提高。

GitLab

• The most-comprehensive AI-powered DevSecOps platform | GitLab

GitLab： GitLab是由Dmitriy Zaporozhets和Valery Sizov于2011年创建的。最初，GitLab只是一个基于Git的代码托管平台，它提供了类似于GitHub的功能，但在自托管方面更加强调。然而，随着时间的推移，GitLab逐渐发展成为一个全面的DevOps平台，为软件开发生命周期的各个阶段提供支持。

对比

Gerrit2界面简单，专注于代码审核以变更集管理：强调逐行代码审核，基于变更集每个变更都是独立的单元，权限控制更细。

Gitlab功能更全面，是一个DevOps平台。单就代码审核的话，比Gerrit2逊色。

其他人总结

• https://zhangmengpl.gitbooks.io/gitlab-guide/content/gitlabvsgerrit.html

风格

1
2

gitlab的特点是一个人维系一个分支。
gerrit的特点是一个团队维系一个分支。（这里的分支对应一个业务需求）

权限

1
2

gitlab提供了比较多的选择，可以根据需要创建project，每个团队可以根据自己的需求管理自己的代码，方式更加的灵活。
gerrit比较单一，而且权限配置比较复杂，往往都是要联系管理员做出修改，每个团队很难做到对代码的个性化管理。

评审

1
2
3

gitlab是以merge request作为一次review，merge request中可能包含多个 commit，如果review不通过也不需要发起另一次merge request。
gerrit是以commit作为一次review，由于changeId的存在，可以对一次commit反复的进行review。
如果task划分的粒度够细的话，并不会影响各个团队的review习惯。

团队协作：

1
2

gitlab可以选择公开代码，团队间可以看到互相的代码，有利于团队的协作。
gerrit由于权限控制问题，只能在权限范围内公开代码。

共享

1
2
3

gitlab 可以提供issues，wiki等功能方便开发者与使用者之间的沟通，并且gitlab可以无缝的与一些项目管理工具集成，比如:jira。
gerrit 这个方面比较欠缺。
gitlab每个项目都有自己的wiki，很方便查看。

维基（MediaWiki） gitlab迁移

2020年，从gerrit迁移到gitalb。他们做了大量评估工作

操作比较

• https://www.mediawiki.org/wiki/GitLab/Gerrit_to_GitLab

比如：

• gerrit能够 -2, -1, 0, 1, 2打分。-2可以阻挡后续进行
• gerrit有dashboards看板，待review的change。可以设置email通知
• gerrit方便添加reviewer人员
• gerrit的评审是基于 commit 而不是 branch 的，粒度更细

迁移决定：

• GitLab consultation - MediaWiki
• [From Gerrit to Gitlab: join the discussion – [WM:TECHBLOG]] (wikimedia.org)
• GitLab - MediaWiki

注意：mediawiki不使用 gitlab的 wiki 等功能，只是用git相关的功能以及review

其他人对 gerrit抱怨

主要是gerrit与后面主流的github、gitlab、bitbucket工作流不太一样。

• Gerrit is Insanity. Why should I use it? : r/git (reddit.com)