Gerrit and me

Gerrit is a git source control server which includes a code review workflow. The code review part of Gerrit is really good, but it is quite different to how GitHub and GitLab implement code reviews.

This post covers:

• Why Gerrit is weird compared to vanilla git.
  • Gerrit thinks in terms of patches, cos that’s how Google thinks.
  • Linear history.
  • The Gerrit server is a customized git server, it can do special things.
  • You need to understand rebasing and rewriting the git history.
  • Don’t think in terms of git branches (mostly).
• How to do git things so that you can use Gerrit for code reviews.
  • The magical git commit hook.
  • The magical commit ID.
  • The magical ‘refs/for’ remotes.
  • Create a CR with git push origin HEAD:refs/for/main
  • Update a CR in response to feedback.
• Useful Gerrit features.
  • Work-in-progress change requests.

Why Gerrit is weird

If you have a Gerrit server, you have a git server. Gerrit is a complete implementation of a git server, all the things you do with any other git server will work with a Gerrit server.

But Gerrit’s git server can also check policies defined at the Gerrit level. It’s a custom git server. Depending on the Gerrit server administrators, things like a git push can be blocked.

Gerrit basics

Git has branches and merges. Gerrit thinks in terms of change requests (patches) and the patch submit (merge).