I’m yet to appreciate gerrit as a code review tool worth to learn (after having heard bad and good stories about its features and how it complements development workflows), but in my new team at Codilime where we develop…a revolutionary machine learning engine enabling your team to use state-of-the-art algorithms in a fraction of time! that’s the tool to conduct code reviews.

The blog post presents how I discovered a way to contribute to a patch set with my own changes. Use with caution as I’m not really sure that’s how gerrit should be used in a team.

Very (lame) intro to gerrit

From the website of gerrit:

Web based code review and project management for Git based projects.

The take away from it is that it’s the tool for code reviews for git project. You git push your changes to master early and often – I’d say it’s even earlier and more often than I did following the github workflow with pull requests or the gitlab workflow with merge requests.

At GitHub and GitLab I usually git rebase changes to squash them all into one and send a pull/merge request.

In gerrit, you git commit --amend as a way to keep changes under a single code review request. The point is to keep Change-Id and you should be fine in a single code review session. Every git push following git commit --amend with a single Change-Id creates a new Patch Set until it’s ready to be merged with master. These Patch Sets (under a single Change-Id) establish a sort of branch from which you send changes for code review.

Once the code looks good, i.e. it’s +1 twice by the team and verified (possibly by Jenkins), it can be submitted to the central git repository - preferably (private) one at GitHub.

Drafts as branches - not for review

There’s a feature of gerrit called drafts that…will be for a change that is not meant for review (yet). It’s a good candidate for changes that other developers can contribute to (I might be mistaken here since I’m new to gerrit).

Contributing to a Patch Set

DISCLAIMER: What follows assumes that a patch set in draft status can be considered a branch to develop collaboratively with a few developers. I’m not so sure it’s a correct assumption.

In gerrit, go to All > Open where you see all the available changes for code review. Pick one, preferrably in Draft status (but others should work fine, too).

Expand the latest Patch Set and select checkout tab in Download. Copy the git fetch ... && git checkout FETCH_HEAD command using the icon on the right (see the screenshot above).

Do your changes and once satisfied git checkout -b new_branch_name to create a new branch as new_branch_name.

git add the changes and very important git commit --amend them with Change-Id untouched. The Change-Id is the way for gerrit to keep track what belongs to what development stream as a new patch set. You may also want to change the author with git commit --amend --author to mark the changes as yours.

Push the commit to origin (or whatever remote repository you use) with git push origin <new_branch_name>:refs/drafts/master. The git push command assumes that you’re on master branch.

You’re done!

See How to change a patchset and push it as a new one? where the knowledge was initially developed.