Gerrit Workflow

The workflow defines a process for using with Google’s Gerrit project. It is excellent in a number of ways! If you are using Git at your company and want to have a nice code review process as well as a way to verify and have a few more checks and balances, this is an amazing tool that Google has provided open source. I did make a few customizations to the tool in order to better suite our needs within the company and maybe I will share those once I get some more free time.

The idea with the following workflow is to show you a developer process from beginning to the end of a feature using Gerrit.  We are not using Repo which is a Google developed tool to work with Git and Gerrit.  We are using straight out of the box Git with Gerrit.  In our company we have a few proprietary development build processes but I try to call those out in the workflow so that you can tell how it could be adapted to your company or open source project.

Workflow

  • Implement feature
  • 1
    2
     //Create topic branch off of master
    git checkout -b topic origin/master
  • Commit changes. Commit as many times as you want to the topic branch.
  • Get latest code frequently and especially before you push.
  • 1
    git pull
  • Fix Merge Conflicts
  • 1
    2
    3
     git mergetool
    //'''Do *NOT*''' commit after you do the merge
    git rebase --continue
  • Compile the code
  • 1
    2
    3
    4
    //This is an internal shortcut for us to do a full compile just like the integration hudson builds
    //You really want to be able to replicate exactly what the integration machines are doing and
    //make it as easy as possible.
    projbuild
  • Validate the code (This means running your unit tests, integration tests, a subset of all the selenium tests, etc.)
  • 1
    projbuild dev_check
  • Prepare a single commit for code review by squashing your commits
  • Create another local branch
  • 1
    git checkout -b topicForCodeReview origin/master
  • Merge squash your topic branch into your topicForCodeReview branch
  • 1
    git merge --squash topic
  • The squash leaves the changes in your topicForCodeReview branch in the staged state. You’ll need to fire up git gui and commit them to that branch.
  • Push for code review
  • 1
    git push for-code-review
  • Fix any merge issues using git mergetool if necessary.
  • Note: If you choose not to squash before pushing for code review, every commit will get a separate code review!! This is not recommended.

Setup

You will need to setup the git config a certain way in order to be able to pull off this workflow.  Pretty trivial changes though, so don’t worry to much yet 🙂

  • Set rebase to always
  • 1
    2
    [core]
      rebase = always
  • Set up the shortcut for “for-code-review”
  • 1
    2
    3
    [remote "for-code-review"]
      url = <main git uploading repository location>
      push = HEAD:refs/for/master

8 thoughts on “Gerrit Workflow

  1. Hello, I recently came accross your blog and have been reading along your posts. I decided I will leave my first comment. I have enjoyed reading your blog. Nice blog. I will keep visiting this blog very often…

  2. Ah, perfect – this is just what I’ve been searching for, all laid out in one nice, concise blog article!

    Thanks so much for this, Ryan!

    –Bruce

  3. Great point! I fixed it up now. Surprised that wasn’t mentioned before now. Let me know if you have other questions.

  4. Nice writeup. You may want to fix this typo here:

    # Push for code review
    1 git pull

    I suppose that should be “git push”. But we also use the new topic name feature of Gerrit.

    git push gerrit HEAD:refs/for/master/myTopicName

    I don’t know if there’s a way to automate that with remote.push, but it would be nice if there were. 🙂

  5. Thanks! I just fixed the typo! Thanks for pointing it out. It would be nice to automate the pushing. So far what I have done is allowing the alias of “git push for-code-review”.

Leave a Reply

Your email address will not be published. Required fields are marked *