We have a lot of repos, mostly private and some that will become public. I've done plenty of code review with github and I've found it wanting. Gerrit seems to provide a more capable review process, but it does have a learning curve. Here are the basics of review.



Resources

git-review adds a new subcommand to git that eases the use of git with gerrit for review.

For macos, brew install git-review, for ubuntu apt install git-review. If you're running an old release of ubuntu, the git will probably be too old. You may need to build git, which is fortunately not hard.

Access to gerrit

The best way of creating a clear path to your gerrit server is to set up an ssh config section such as the following:

Host gerrit
Hostname gerrit-server.your-domain
User <gerrit username>
Port 29418

Then log on to your gerrit web dashboard, and add your ssh public key in your account settings.

Preparing your local git checkout

git review will take care of the following, but this is one way of handling the generation of the Change-Id line in the commit message:

scp -p -P 29418 <user>@<GerritHostServer>:hooks/commit-msg .git/hooks

reference: How to use git-review

Gerrit workflow

git-review likes to have the remote name be gerrit, so a clone looks like this:

git clone -o gerrit gerrit:demo

If you have a repo that is moving to gerrit and coming from another repo, add the remote:

git remote add gerrit gerrit:demo

Initialize the local repo (this is idempotent):

git review -s

This in effect does the following (which you do not need to manually do):

scp -p -P 29418 <user>@<GerritHostServer>:hooks/commit-msg .git/hooks

Create a feature branch to make changes on:

git checkout -b feature/party

Make your changes, stage and commit. Make a bunch of commits. If you do that latter, you'll want to squash before sending it to review. Here's an example:

$ git glog
* e2f45ded3e (HEAD -> refs/heads/feature/party) change sample
* f31d4b8c4e add party
* d8673f9837 (refs/remotes/gerrit/master, refs/remotes/gerrit/HEAD, refs/heads/master) update sample add a new line
* df6ff464a0 first change
* cb481ea469 Initial empty repository

$ git rebase -i d8673f9837
[detached HEAD 8fc3b4c] add party
 Date: Thu Mar 14 23:01:25 2019 -0400
 2 files changed, 3 insertions(+)
 create mode 100644 party.txt
Successfully rebased and updated refs/heads/feature/party.

$ git glog
* 8fc3b4c2f5 (HEAD -> refs/heads/feature/party) add party
* d8673f9837 (refs/remotes/gerrit/master, refs/remotes/gerrit/HEAD, refs/heads/master) update sample add a new line
* df6ff464a0 first change
* cb481ea469 Initial empty repository

The rebase happens on top of the last commit you don't want to be squashed, in this case I wanted to roll 'add party' and 'change sample' into one commit that followed master and became the only commit in feature/party. When in the interactive rebase (the -i), leave the first line as 'pick' and change the rest to 's' (for squash). All the commit messages will become part of the new single commit.

Now this can be submitted for review:

$ git review
remote:
remote: Processing changes: refs: 1, new: 1
remote: Processing changes: refs: 1, new: 1
remote: Processing changes: refs: 1, new: 1
remote: Processing changes: refs: 1, new: 1, done
remote:
remote: SUCCESS
remote:
remote: New Changes:
remote:   https://code-review/c/demo/+/64 add party
To gerrit:demo
 * [new branch]      HEAD -> refs/for/master%topic=feature/party

You can see what's pending for review:

$ git review -l
64  master  add party
Found 1 items for review

Now it's time to go to the gerrit web interface to see what's there. During review, if changes need to be made, they should be sent as a patchset to the review. The way to do this is:

git review -d 64
<make your edits>
git add -u
git add other/new/files
git commit --amend
git review

The --amend is super important. If you forget that, a new review will be created instead of adding a patch to the single review.