This is an opinionated step-by-step guide for how to not screw up working with Gerrit as a code review tool.
This presumes a setup where you're working on a forked copy of the repository and have created an "upstream" remote repository which points to the original.
Pull/rebase the latest changes from upstream into your master branch:
git pull --rebase upstream master
If you're working from a fork, push your fresh changes from upstream master to your master:
git push origin master
Commit your changes to a topic branch:
git commit -a -m "I made some changes!"
If you made multiple commits, or this is a fix on a previous review, see the sections on squashing/fixing below.
Run
git review
.
If you've made several commits to your topic branch you'll want to squash them into a single commit prior to sending it to Gerrit. (When gerrit receives multiple commits in a review it opens a new review for each one and they're all made dependents of each other.)
Run a
git rebase
command with the appropriate number of commits you want to merge together. An example squashing the last two commits:git rebase -i HEAD~2
The next screen will allow you to select what to do with the commits. In general you'll leave the first commit as a
pick (p)
and mark all but rest assquash (s)
.The final screen allows you to edit the final commit message for the squashed changes. Make sure you leave the first
Commit-Id
line from the commits. That commit id will be tied to your gerrit review permanently. This is important when updating/amending a review.
If you submitted a review and got feedback that required code changes, you don't have to abandon your previous review and start over. In fact, that's a bad thing to do as you lose the thread of conversation.
The steps for squashing above work fine, but alternatively you can use the
fix (f)
option of git rebase -i
to merge commits without having to
edit the commit message. The changes will be merged, but all "fixed" commits
have their commit messages discarded.