GerritとGitLabの比較

Gerrit は無料の Web ベースのチーム用のソースコードコラボレーションツールです。ソフトウェア開発チームの開発者は、Web ブラウザーを使用してお互いのソースコードの変更をレビューし、それらの変更を承認または拒否できます。Gerrit は別のコードレビューツールである Rietveld のフォークです。

On this page

Summary

Gerrit is a free, web-based team code collaboration tool. Software developers in a team can review each other's modifications on their source code using a Web browser and approve or reject those changes. It integrates closely with Git. It was originally developed as a code review system for Android development. Gerrit includes code diffs, discussions, a and a git server.

In contrast, GitLab provides a git server, with issues and issue tracking, as well as code review, and features to automate the entire DevOps lifecycle.

Comments/Anecdotes

  • From a customer who used Gerrit:
    • Code Review lacked collaboration and communication: commit had 1 single thread, review by commit instead of branch.
    • Wanted to set up forks but Gerrit has no concept of forks
    • Unable to delete projects, creates a cluttered namespace
    • No group ability
    • Not intuitive - additional training required for any more complex workflows
  • From GitLab Solutions Architect who used to work with Gerrit:

    Gerrit takes a different approach to branching than standard Git. In Gerrit, essentially every branch is a protected branch, but there is a much lower need for branches because Gerrit will create them automatically as they’re needed. As a developer, I can work on the master branch, and when I push to origin, Gerrit automatically creates a “virtual” branch called refs/for/master in the origin and puts my change on that branch. This is similar to the GitLab merge request creating a branch when the MR is created in an issue. The difference is that there are refs/for/master is virtual and so there are many - I have a refs/for/master, you have a refs/for/master, each person who pushes has one in the origin repo. The changes are held on this virtual branch until the review is completed per the rules, at which time it’s merged and the virtual branch is deleted. Gerrit really encourages merging to master and maintaining only one branch, which is a best practice, I think. The default Gerrit workflow is actually very similar to GitLab Flow but is different from GitHub or FOSS Git.

    Gerrit has a Jenkins plugin that knows a lot about Gerrit. When I push to origin, Gerrit can kick off a Jenkins build by triggering Jenkins rather than by Jenkins polling Gerrit. Gerrit passes the refs/for/master branch info so Jenkins builds just the change that was pushed. The Review request can be set up to require a successful build (verification) and the reviewers won’t even be notified they have a review to do until the build is successful.

    Rules can be set up for things like “successful build plus one reviewer” or “successful build plus two reviewers”. So the build gives a +1 on verification, and then each reviewer can give +1 on the review.

    Reviews are different than merge requests because you may assign reviews to people that wouldn’t normally have merge permissions on a branch. For example, a senior developer or architect may make a change that she wants a junior engineer to learn from. She can add that person to the review and give them a way to manage reviewing the change. This may be similar to the Approver field on a merge request.

    Gerrit supports read and write privileges on branches, not just write privileges. This makes it more appealing to regulated industries like defense and orgs that use a lot of contractors and may not want an entire repo going on the laptop of a contractor. It’s easier to assign permissions than it is to break up a repo into parts the contractor can see and parts they can’t. This is why CollabNet chose Gerrit as it’s Git of choice because it enabled them to do branch level permissions in Git like they do in Subversion.

    Negatives:

    • Gerrit has lots of options. Lots. The options page is reminiscent of the cockpit of a 747 there are so many switches. This makes it tough to adopt for teams without dedicated Gerrit experts and/or expert developers.
    • Gerrit doesn’t use the standard hook scripts, so migrating to/from Gerrit where process is enforced by pre-commit hooks takes extra work, potentially lots of extra work.

    There are a lot of similarities between GitLab with Merge Requests and CI Pipelines and Gerrit with Jenkins, similarities that other Gits don’t have, nor does Jenkins by itself.

Resources

Comparison

機能

コミュニティによるサポート

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

GitLabコミュニティフォーラムは、すべてGitLabユーザのための活発なコミュニティで、情報共有やサポートを得られる場です。

コミュニティフォーラムを表示

画像に関する議論

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

コミット画面やマージリクエストの差分画面で、画像の特定の位置を指定して、画像に関する議論をコメントできます。1つの画像に対して複数の議論を作成できます。

画像に関する議論

マージリクエストのコミットに関する議論

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

マージリクエストのコミットに対してコメントをすることができます。

マージリクエストのコミットに関する議論

コードレビューを複数人で承認

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

GitLab では厳密なコードレビューを保証するために、マージリクエストをマージする前に、 マージリクエストに対して様々なユーザーからの特定の数の承認 を要求することができます。一度承認した後で問題に気がついた場合は、承認を取り消すこともできます。

承認機能のドキュメント

コードレビューの承認ルール

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

適格な承認者のリスト、それぞれの承認数の最小値、 およびどのターゲットブランチを保護するかを指定して、 承認ルールに沿って適切な人がマージリクエストをレビューするようにします。これにより、 エンジニアリング、UX、プロダクトといった異なるチームにレビューを依頼することが容易になります。

承認機能のドキュメント

マージの承認

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

GitLab Enterprize Editionではマージリクエストをマージするのに、複数の承認を必須とすることができます。マージに必要な承認の数や承認可能なユーザーを設定することは、コード品質の改善につながります。

マージリクエストの承認の詳細

インラインコメントと議論の解決

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

マージリクエストのインラインコメントを使用すると、コードやテキストのレビューがより高速かつ効果的になります。特定のコード行についてコメントを残し、議論を解決します。GitLab では、マージリクエストのインラインコメントは議論として解釈され、変更されてもされなくても任意の行に残すことができます。すべての議論が解決されたときにのみマージリクエストが承認されるようにプロジェクトを構成できます。

議論の解決の詳細

コードオーナー

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

ファイルにコードオーナーを割り当てて、 CODEOWNERS ファイルを使用してプロジェクトのコードを担当するチームメンバーを指定します。コードオーナーはマージリクエストの承認者として自動的に割り当てられ、必要に応じて設定し、ファイルを表示するときにそれらを表示できます。

コードオーナーの詳細

Git プロトコル v2 サポート

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

Git のワイヤプロトコルは、クライアントとサーバの間でクローン、フェッチ、プッシュがどのように通信されるかを定義します。Git プロトコル v2 は、フェッチコマンドのパフォーマンスを改善し、将来のプロトコル改善を可能にします。

Git プロトコル v2の詳細

コードレビューダッシュボード

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

フィルター可能なコードレビューのセット (プロジェクト、ユーザー、ブランチ、ステータス、もしくはそれらの組み合わせ) を含むダッシュボードです。ダッシュボードには、コードレビューのステータスとそれらにアクセスするリンクが含まれます。これにより、目的のサブセットのコードレビューで行われていることを簡単に確認できます。

GitLab でのコードレビュー

貢献者の規約

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

ユーザーはプロジェクトの変更を送信する前に、1つ以上の貢献者規約に署名する必要があります。

この課題の詳細を確認

ロボットのコメント

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

自動化されたサードパーティシステムによって生成されるインラインコメントをサポートします。例えば、ロボットのコメントを使用してコードアナライザーの結果を表すことができます。

GitLab のマージリクエストでのストア結果

複数のリポジトリタイプで動作します。

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

Git, Subversion, Perforce, CVS, Mercurial などの複数のリポジトリタイプをサポートします。

他の SCM からの移行の詳細

投票に基づくマージの許可/拒否

CORE
STARTER
PREMIUM
ULTIMATE
FREE
BRONZE
SILVER
GOLD

レビュアからの投票結果に基づいてマージを許可/拒否します。変更のマージを決定するときの柔軟性が向上します。

この課題の詳細を確認

* このページの情報は最新ではありません。最新の情報は 本家サイト をご確認ください。

GitLabはGitLab, Inc.の商標です。その他のすべての商標・ロゴマークの権利はそれぞれの所有者に帰属します。

GitLabはオープンコア

GitLabの競合製品のほとんどはソースコードを公開していませんが、GitLabはオープンコア製品です。 GitLabコミュニティエディションは完全なオープンソースで、 GitLabエンタープライズエディションはオープンコア(プロプライエタリ)です。

ソースコードにアクセス

クローズドソースなソフトウェアと異なり、 コミュニティエディションエンタープライズエディションの ソースコードを確認したり、修正することができます。 機能の追加やカスタマイズのために、サーバーのソースコードを修正したり、GitLabのリポジトリをフォークすることができます。 独自に実施した変更はメインのソースコードにフィードバックし、マージされるように挑戦することを推奨します。 それにより、他のユーザーの役に立つ上に、自身のインスタンスのアップデート作業を簡単に保つことができます。

コミュニティからの貢献

GitLabには毎月数百人からの貢献があります。 顧客・ユーザー・GitLab社員のすべてが毎月のリリースに貢献しています。 このことは、簡単に使用できる便利なユーザー管理のような、 組織にとって本当に必要な機能の開発に役立っています。

長期利用に最適

GitLabは、数十万の組織が利用し、頻繁にソフトウェアへ貢献しています。 GitLabには堅牢なコミュニティが存在します。 つまり、GitLabは単一企業のサポートに依存していないので、 長期利用に適しています。

毎月、新しい安定版がリリース

毎月、機能の改善と新機能の追加と不具合の修正のすべてが適用された、 GitLabの新しい安定版がリリースされます。 これにより、GitLabはとても迅速に顧客の要望に応えることができます。

オンライン「GitLabトレーニング(初級)」申し込み受付中

開催日: 2020年9月8日(火)・9日(水) / 10月6日(火)・7日(水)

Gitlab x icon svg