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