GitLab compared to other DevOps tools

Gerrit vs GitLab

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. Gerrit is a fork of Rietveld, another code review tool.

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

FEATURES

Community Supported

The GitLab Community Forum is an active and vibrant place for all GitLab users to share and seek support.

Visit the GitLab Community Forum

Image Discussions

Within a commit view or a merge request diff view, and with respect to a specific location of an image, you can have a resolvable discussion. Have multiple discussions specifying different areas of an image.

Image Discussions

Merge Request Commit Discussions

Comment on a commit within the context of a merge request itself

Merge Request Commit Discussions

Multiple approvals in code review

In GitLab, to ensure strict code review, you can require a specific number of approvals on a merge request by different users before being able to merge it. You can undo an approval by removing it after the fact.

Approvals Documentation

Merge approvals

When a project requires multiple sign-offs, GitLab Enterprise Edition enables you to make sure every merge request is approved by one or more people. Merge request approvals allow you to set the number of necessary approvals and predefine a list of approvers that will need to approve every merge request in a project, and in-turn improve your code’s quality.

Learn more about merge request approvals

Inline commenting and discussion resolution

Code or text review is faster and more effective with inline comments in merge requests. Leave comments and resolve discussions on specific lines of code. In GitLab, Merge Request inline comments are interpreted as a discussion. You can configure your project to only accept merge requests when all discussions are resolved.

Learn more about resolving discussions

Code Owners

Assign Code Owners to files to indicate the team members responsible for code in your project using a CODEOWNERS file. Code owners are suggested as merge request approvers, and shown when viewing files.

Learn more about Code Owners

Git protocol v2 support

Git’s wire protocol defines how clones, fetches and pushes are communicated between the client and server. Git protocol v2 improves performance of fetch commands and enables future protocol improvements.

Learn more about Git protocol v2

Code review dashboards

Dashboards with a filterable set of code reviews (could be by project, by user, by branch, by status, or a combination of those). Dashboards includes code review status and links to get to them. This makes it easy to see what is going on with code reviews for a desired subset.

Code review with GitLab

Contributor agreements

Users can be required to sign one or more contributor agreements before being able to submit a change in a project.

Read more on the issue

Robot comments

Support for inline comments that are generated by automated third-party systems, for example robot comments can be used to represent the results of code analyzers.

GitLab merge requests store results

Works with multiple repository types

Supports more than one repository type, such as Git, Subversion, Perforce, CVS, Mercurial.

Learn about migrating from other SCMs

Allow/deny merge based on votes

Allow or deny a merge based on vote tally from reviewers. Provides more flexibility in determining whether to merge changes or not.

Read more on the issue

Download as PDF

If you feel there are inaccurate statements in this comparison, please edit this page or propose edits by creating an issue. When creating an issue, please use the "Comparison page" template and assign to @dangordon to ensure we see your suggested changes. You can also send an email to dgordon@gitlab.com with your suggested edits if you're unable to create an issue or edit this page.

We strive for technical accuracy and will review and update this post for inaccuracies as quickly as possible.

GitLab is the trademark of GitLab, Inc. All other logos and trademarks are the logos and trademarks of their respective owners.

Try GitLab Ultimate risk-free for 30 days.

No credit card required. Have questions? Contact us.

Try GitLab Ultimate risk-free for 30 days.

No credit card required. Have questions? Contact us.