Working with Git and Gerrit » History » Revision 3

« Previous | Revision 3/46 (diff) | Next »
Karsten Dambekalns, 2010-07-24 11:37

Working with Git and Gerrit Code Review

Note: We have not yet switched to Git and Gerrit, but are currently in the process of doing so.

For FLOW3 and TYPO3 Phoenix we are using Git and the Gerrit Code Review system to channel commits for review. Gerrit is integrated with our CI setup based on Hudson to have automated pre-tested commits.

Now here is what you need to know to contribute, more details on Git are available in the Pro Git book and other resources.


Getting Git

Firstly, if your machine doesn't already have it installed, get a copy of the 'git' version control system. This is available for many platforms from their upstream package repositories or, failing that, can be downloaded in both source and binary form from

If you look for a GUI tool to use with git, you can use the built-in GUI by starting gitk from the command line. For Windows there is TortoiseGit, on the Mac you can use gitx and for all platforms (Mac, Linux, Windows) there is SmartGit - more tools exist, if those don't fit your needs.

First-time Git setup

You must tell git a little about yourself so it knows who you are when doing commits. So simply do this:

$ git config --global "John Doe" 
$ git config --global

More details and helpful configuration options are explained in the Pro Git book, chapter 1.5

Getting the codebase

You can download the repository for a project by running

git clone git://<projectname>.git

to place the clone in a directory called like the project or
git clone git://<projectname>.git <name-of-directory>

to place your clone in a specific directory.

This will give you a complete copy of the repository and unless you are exceptionally short of either disk space, or time, is the approach we recommend. Unlike with Subversion, you are not just checking out a particular branch, but making a local copy of the project's whole revision history, across all of it's branches. This does make the download pretty large - but makes daily work with Git blazingly fast and allows for all the goodies of a distributed SCM.

Updating the local copy

When you want to update the local repository with the central one, running

git pull

will pull all of the new changes into your local repository, and merge those changes into your correct working tree. Note that whilst this is fine when you are browsing the repository, you may want to exercise more control over how upstream changes are merged into your development code.

Working on the code

We strongly recommend that you do all of your development upon 'topic branches.' This allows you to isolate multiple unrelated changes, and makes it easier to keep your tree in sync with the upstream one.

Before creating a new topic branch, running

git fetch

will make sure that your repository knows about the latest upstream changes (unlike git pull, this will not update any files that you may have checked out).

To create a new topic branch:

git checkout -b <branch>

For example, to work on a patch to fix ereg warnings, based on the current development code, I would do:
git checkout -b fix-ereg-warnings origin/master

This puts me on a new branch, ready to start writing code. All new development should be based upon the origin/master branch, submissions based upon other branches are unlikely to be accepted, unless they address issues that are solely present in that branch.

To tell git about any new files you create as part of your patch

git add

is used. If your patch results in any new byproducts (cache, metadata files, etc) that git should not be tracking, please make sure that they're caught by the .gitignore mechanism. You can do this by checking that they don't appear in the output from git status

git mv and git rm are used to move and delete files respectively.

git commit -a
is used to commit code to all of the files that git is currently tracking (that is, all of the files that you have checked out from the repository, and all those which you have run git add on)

Be sure to explore the power of staging your changes: unlike with Subversion you can stage some changes to a file for commit while not (yet) stage other changes to the same file. This can come in very handy. To shelve work in progress, have a look at git stash.

When you can't see the wood for the trees

If, in the middle of development, you discover that you've gone down a blind alley, and wish to go back to the state of your last commit

git reset --hard

will discard all of the changes you have made since the last commit, or
git checkout -f <file>

will restore <file> to the state it was in at the last commit.

Keeping up with upstream changes

If you're working on a long running development project, you will find that the point your created your topic branch rapidly recedes into history. At some point (and at least before you share your code with us), you'll probably want to update your tree. There are a number of ways of doing this.

If you haven't shared your tree with anyone else, then you can use

git rebase <branch> <topic>

(Where <branch> is the name of the upstream branch - for example origin/master, and <topic> is the name of the topic branch you are currently working on)

Note that git rebase changes your local history (it moves the branch point of your topic branch to the tip of the upstream branch), and is a bad idea if others have cloned your repository. See man git-rebase for more details.

If you can't rebase, then consider either merging the changes onto your local branch, or creating a new topic branch and cherry picking your changes onto it. The man pages for git merge and git cherry-pick provide more detail on these options.

Sharing your code with us

How you work from this point onwards depends on how you intend making your code available to us. We're still happy to receive submission by patch (attach the patch to the issue you created or worked on using the Forge), but it makes it much easier for us if you push directly from your git tree to our code review system, gerrit.

Registering with gerrit

To register with gerrit, visit and log in using your username.

If, when you introduced yourself to git, you gave it a different email address than the one gerrit currently has listed for you, you need to introduce yourself to gerrit under that name, too. Click on 'Contact Information', and select "Register New Email...". If gerrit thinks you are an "Anonymous Coward" then you can fix that on this page as well.
In order to be able to upload code, you now need to create a ssh key that gerrit can use to identify you, or tell gerrit about one that already exists.

To create a new ssh key, if you don't already have one, run

ssh-keygen -t rsa -f ~/.ssh/id_rsa

The public key for this is now stored in ~/.ssh/
To tell gerrit about your key, log in, and go to 'Settings'. Select 'SSH Keys', and paste your public key into the "Add SSH Public Key" box, or click on the 'Open Key...' option to load it from the filesystem. Click on 'Add' to add the new public key. While you are on this page, make a note of your 'SSH Username', because you'll need to for the next step.
To make things easier, set up OpenSSH so that it knows about the defaults for the gerrit server. Edit ~/.ssh/config, and add a section like:
User <SSH Username> 
IdentityFile ~/.ssh/id_rsa 
Port 29418

(where SSH Username is what you were told on the the 'SSH Keys' page)

The change id hook

Gerrit introduces the concept of "change IDs". This is a unique reference for a particular change, which remains constant regardless of any changes that are made to the implementation. This allows a single reference to be attached to a given modification, irrespective of any rewrites that may occur as a result of review comments. Manually maintaining change Ids is a pain, so gerrit provides a git hook which can be used to automatically add a change Id to any new modifications you create.

In our git repositories the hook is already included when you clone and should be in .git/hooks/commit-msg. If, for whatever reason, it is not or you need a fresh copy of it, the hook can be downloaded from the gerrit server by running the following, in the top level of your git tree

scp -p -P 29418 .git/hooks/

Uploading to gerrit

When submitting to gerrit, it's important to realise that each commit in your branch will become a changeset in the upstream codebase, typically with no modification at our end. It is therefore important that these commits follow some simple rules...

First, each commit should be complete. The rule "one change per commit, one commit per change" applies here. Each commit should build and test in its own right. Typically, this means that a change will be in a small number of commits. If, during development, you have created many more than this (for example, you've created a large number of bug fix commits), please use 'git rebase', or cherry pick these commits into a separate tree before uploading them.

Secondly, each commit should have a meaningful revision log message. The internals of git means that we can't easily edit these before pushing them into the tree, so we'd like you to get them right for us! A commit message should be comprised of a single 'subject' line (which must not end with a full stop), followed by a blank line, followed by one or more paragraphs explaining the purpose of the patch. The usual rules for relating to Forge issues apply (see FLOW3 CGL). Here is more information on git revision log conventions

Once you have commits in this form, use

git log -p origin/<branch>..HEAD

(where <branch> is the upstream branch upon which you are basing this patch). to check that what you're giving us makes sense. Then, upload them to gerrit using
git push ssh://<projectname>.git HEAD:refs/for/<branch>

(again <branch> is the name of the upstream branch that you are pushing the changes into, not the name of any local branch you may have been developing on).

In this case, 'refs/for' is a literal string. So, if you had been developing against master, you can upload your changes with:

git push ssh://<projectname>.git HEAD:refs/for/master

This relies upon the ssh configuration you performed earlier. If it fails to work, please consult the gerrit troubleshooting notes

Assuming all has gone well, this will have added the entry to the code review queue. The output from git review will give you a change number - this is a unique reference for this particular set of changes. During review you'll be emailed with any comments anyone makes, and can respond to those comments using the gerrit web interface (see the section on reviewing, below). It's possible that issues with your change may be noticed during the review process, and you may be asked to revise it, or update changes to the tip of the tree.

Revising your change

It's possible that your modifications won't be accepted first time. In this case, you need to revise your changes, and resubmit them to gerrit. Please note that this should always be done by modifying your original changeset, not by submitting a new change that makes the required fixes. Either git commit --amend, or git rebase should be used to combine your changes with the original changeset, and then you should push this to gerrit with

git push ssh://<projectname>.git <hash>:refs/changes/<number>

(where <hash> is the sha1 hash of the revised change, and <number> is the change number you received when you originally submitted the patch).

You can obtain the sha1 hash of a commit by using 'git show' (if it is on the tip of your current branch), or 'git log' (if it is in your history).

Other mechanisms of listing the change to push are available - see for full details.

Updating your change

It's possible that your change may have been made against a tree which is too old for it to apply to the tip. In this case, gerrit will let you know that there is a collision, and request that you update the change to the tip.

You can do this with

git rebase origin/master <topic>

(assuming your patch is against the 'master' git branch, and lives on the <topic> branch).

And then simply resubmit your change in the same way as if you had been asked to revise it (see notes above)

Submitting by patch

If all of this seems too daunting (and please don't let it put you off) you can still, of course, submit patches by email.

git diff HEAD

will give you the set of changes if you don't do local commits. If you make topic branches, and commit things locally, but don't want to go through the whole gerrit process,
git diff master..<topic>

will give all of the changes between the branch point of you topic branch (assuming you branched from 'master') and the last commit.
You can attach those to issues in the Forge issue trackers as before. Note, however, by doing this you're making someone else take the patch, create a topic branch in their local tree, apply the patch, and push it into gerrit.

Things would be much more efficient if you pushed into gerrit yourself. Please?

Reviewing changes

We'll now look at how changes that have made it into gerrit can be reviewed. All code review now happens via the interface. You should log in there as detailed above (using your user credentials), and make sure that the email address points to somewhere you'll read regularly.

You'll be presented with a list of patches requiring review or, if someone has asked, patches you've been explicitly requested to review. There are two types of review - Code Review and Verification. Code Review means that you have read through the code, and are satisified that it works properly, follows the tree's style, and generally doesn't suck. Verification means that you have taken a copy of the patch and tested it. We will automate the verification step through our CI server Hudson, but generally both should be perfomed (also) manually.

To perform a code review, go through each of the diffs in the current changeset for the code you have decided to review. You can double click on a line to leave a comment. Once you have completed commenting, click on the 'Review' button that's about 3/4 of the way down the page containing the list of patch sets. You will then be asked to score the patch, with a range from -1 to +1. -1 means that you don't think the code should be applied, +1 means that it is good to apply. You can also leave further, general, comments for the patch submitter.

Note that no matter how many +1 or -1 comments a patch receives, the team members can override these to either permit or forbid submission by giving -2 or +2 on a patch ("gatekeeper" permissions). Also, at least one team member must approve a patch in this way before it can be submitted to the tree. In a specific project certain additional rules may applay as to who is allowed to give final acknowlegdement, so make sure to know what you are doing.

To verify the code, pull the git copy into your local tree, using the git command listed as part of the patch details. For sanity's sake, we'd strongly recommend you do this pull into a topic branch you've created for the purpose. Build it, test it, and report your results. Note that a single -1 to verification can block patch submission, so please use these options wisely. If in doubt, score 0 and leave your comments. Please indicate when verifying which platforms you have tested on, and what testing you performed.


... to the folks over at OpenAFS that made us stumble over gerrit and whose wiki page we shamelessly used as a base for this page.

... to Sebastian Kurfürst, Peter Niederlag for their help with git, gerrit and redmine.

... to the TYPO3 Core Team for being open towards a change in SCM flavor.

Updated by Karsten Dambekalns over 10 years ago · 3 revisions