Category Archives: GIT

Gerrit Workflow

Posted on by

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

Git Workflow – In Response

Posted on by

Just wanted to share the following with others since it is in response to a yammer post within my organization.  Maybe it will be slightly helpful to others.  I do realize I am leaving a large part of the thread out of this.  Hopefully I will be able to come back later and actually post our Git workflow.

———–

Git does allow a lot of flexibility in setting up a workflow. It is essential to understand the workflow possibilities and tweak that to fit the organization. Steven has a good point that it is possible to push such that you re-write history. While this is allowed, it can easily be turned off and set by access permissions and/or server side hooks. This is controlled and managed using Gerrit for our team. That way only a limited number of people have the ability to force change history.

There was mention of using “rebase” to change the workflow. From my experience, this has improved the workflow in Git. Our team has “rebase = always” setup so that anyone making a branch will automatically get it setup to be rebased onto the latest code. When anyone sets up a Git repo they run a small setup script that does the aforementioned and some additional tweaks for our workflow. A benefit that you get with using rebase is that your git history is much easier to read since you are really committing only fast-forward changes (less actual merge commits – kind of to John’s point). Since we push everything through Gerrit, developers have the opportunity to do a code review, check their changes, and copy anyone on the change *before* it gets committed to the active development stream.