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
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
See How to change a patchset and push it as a new one? where the knowledge was initially developed.