Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Gerrit vs Github for code review and codebase management

Gerrit vs Github: for code review and codebase management

Sure, Github wins on the UI. Hands down. But, despite my initial annoyance with Gerrit when I first started using it almost a year ago, I am now a convert. Fully. Let me tell you why.

Note: This is an opinionated (on purpose) piece. I assume your preferences are like mine on certain ideas, such as:

  • Fast-forward submits to the target branch are better than allowing merge commits to the target branch. The reason I personally prefer this is that, even if a non-conflicting merge to the target branch is possible, the fact that the review/pull request is not up to date with the latest on the target branch means feature branch test suite runs in the CI pipeline reporting on the review/PR may not be accurate. Another minor point is that forced merge commits are annoying as fuck (opinion) and clutter up Git log histories unnecessarily and I prefer clean histories.
  • Atomic/related changes all in one commit is something worth striving for. Having your developers think about the granularity of their commits in terms of relatedness, cohesiveness, and deployment units makes the changes more manageable. This is my claim and the only evidence I have of it is the difference I have witnessed on teams that went from 1..N commits per feature branch to 1 commit per feature branch. The difference I saw was an awareness one. Developers started to think about viability of deployment of that one unit of change to each of the environments. That wasn't the case before we made the change to one commit per feature branch policy. You can enforce this using Github even, but it's not provided by the Github interface.
  • Being able to publish a review in draft form without prefixing with "WIP" or other general convention (which is totally possible and scriptable in Github; I know I have done it previously) simply makes querying and permission/visibility of those reviews/PRs easier to manage and filter out/in when necessary. Perhaps a minor point.
  • Limiting permissions can provide some merits to helping manage releases and codebase repositories more consistently via automated builds/CI/CD setups.

If you disagree with the above opinions then you will likely not agree with some or more of the following which is why I think Gerrit is better as an overall solution:

  • Gerrit's reviews can be forced to be fast-forward only or rebasable-only. Github's PRs are merge based, which - frankly - disgusts me (just a little). I talk about this above a little but I should warn you of my biases: previously I built CI/CD tooling using Github workflow and it was impossible to reason about the change in a PR now matter what hooks and checks we had on the repository per PR without a LOT of extra work on the tool developer (me). And it wasn't even full coverage of the workarounds I really wanted as a CI/CD pipeline builder. Lots of busy work for very very little value (and a nice UI, sure, I still love Github web UI, but there has to be much more to a trusted partner than a pretty face).
  • Github's PRs do not force you to think about atomic/related changes as one commit. Gerrit's reviews, by its restrictions (i.e. one commit per review), do force developers to think about this much more consciously. I think this is good. Great even.
  • Github's PRs do not track the notion of review rating except loosely in the comments (which are free form). Gerrit's reviews do track this.
  • Gerrit allows you to push draft reviews. There is no such notion in Github.
  • If you want to use the rebase and squash approach in Github (because it's the most sensible, come on) then you can't track the whole history in the pull request. This is a problem. For example, if I provide inline feedback in a pull request and the other developer makes changes based on my comments, I can't view side by side in the UI the diff between the original pull request commit and the new commit without trying to track down the SHA commitish of the original, which is not necessarily easy to find (and not shown in the Github pull request history at all).
  • On the one hand I like that git itself doesn't bake into it a permission model on the repository level, but I do like Gerrit's permission model ON TOP of git. At first I thought it was overkill and sometimes it is. However, I love the idea that in Gerrit I can make it such that only the CI user (e.g. jenkins or travis user) can create tags and push to the Gerrit remote. In this case, only on specific CI triggers are tags created. Tags can't accidentally be created by a developer and pushed to the remote. I'm a fan of consistency and operationalizing release management wherever possible so this is dear to my heart. There are other important areas where I think limiting access to certain features on the repository are useful too, this was just one example.

What Gerrit needs to improve:

  • More coverage of command line options in one place (right now there is gerrit-review and git-review, it would be great to consolidate the CLI consistently for as many of the features available as possible)
  • Better tig integration (which is on the user to update their .tigrc file and new bindings, etc.)
  • Less cluttered UI.
  • More intuitive UI (navigation, etc.)
Owner
mbbx6spp commented Oct 9, 2014

Note: I don't hate Github at all, but the PRs being merge-based are...a big sticking point for me.

Great Analysis! Really interesting point of view from someone who uses Gerrit.
I'm Mariano and I'm building Gitcolony (http://gitcolony.co) and we are redefining the way code reviews are done now.

I would love to get your feedback :)

giftig commented Jun 17, 2015

I agree; despite the UI annoyances, I find Gerrit better to work with.

forced merge commits are annoying a fuck

But I think you meant something else, unless you intended to call yourself a fuck.
I'll show myself out.

Owner

@giftig thanks for the typo correction :)

Fixed. Just saw this. Sorry for delay.

MXWest commented Dec 11, 2015
Github's PRs are merge based, which - frankly - disgusts me (just a little).

Fabulous gist and this was my favorite bit.

omouse commented Mar 29, 2016

If you want to use the rebase and squash approach in Github (because it's the most sensible, come on) then you can't track the whole history in the pull request. This is a problem. For example, if I provide inline feedback in a pull request and the other developer makes changes based on my comments, I can't view side by side in the UI the diff between the original pull request commit and the new commit without trying to track down the SHA commitish of the original, which is not necessarily easy to find (and not shown in the Github pull request history at all).

This is what bugs me the most and why I dislike doing rebase & squash for my own code. I like seeing all the commits and comments that led up to the feature, I like having that history there. But when you rebase and squash with Github, that history is lost.

It's nice to know that Gerrit has a way around that.

armtuk commented Jul 12, 2016

I will never understand why people think rebase and squash is okay. You are losing context and history, you're making a destructive change to the repository, and losing information. "Forcing" developers to make atomic changes in a large corporation just doesn't work. Particularly for those who are your best people, they like to clean things up as they go, and that work "technically" isn't in the original needed work, but god you want to make sure it's included in the PR.

@armtuk I work at eBay and atomic changes work quite well for us. With gerrit we have to focus a bit more on making sure the change is right before it gets merged. As for losing context: What counts in the end is that a change lands on master. With rebasing you push the merge effort to the maintainer of the change.

I just did a code review on public github with comments and multiple commits and IMO this is a mess. What I care about is the final change and not how you got there.

amoghe commented Sep 15, 2016

What I care about is the final change and not how you got there.

Agreed. The "how you got there" (iterations, incorporating coworkers comments as part of the review process) is held in gerrit, outside of git. Thus its important to link the commit back to the gerrit review Id so you can quickly look at how the patch evolved.

Xanir commented Oct 26, 2016

This is what bugs me the most and why I dislike doing rebase & squash for my own code. I like seeing all the commits and comments that led up to the feature, I like having that history there. But when you rebase and squash with Github, that history is lost.

How is the full development thought process via the history useful? The changes committed locally are used as a way to back up the current changes so I can switch to a different branch or revert to point the code was previous working if I break something. When the change is complete the feature should be functional and that 'development' history is moot.

Here is a contrived but very real example. Say I add some code to a services file. Commit the change, locally. Decide that code is too large enough and move it into its own file. Commit that change, locally. I Realize I spelled the new file incorrectly and correct the spelling. Commit the change locally.
Without squashing these changes before initialing a pull request all these development iterations exist in the shared history, what value are they adding?

Gerrit's intent is to help keep your Git history lean, making comparing your changes easier as you only have 1 commit to compare against per feature not 'N'.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment