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 masterIf you're working from a fork, push your fresh changes from upstream master to your master:
git push origin masterCommit 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 rebasecommand 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-Idline 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.