Our Git Workflow and Build Processes

The purpose of this post is to document how my team is using Git.  I will discuss our Git workflow and how we use git hooks to streamline our build process.  We use Bamboo for our build processes and I will discuss how we automate our builds (including database code) using Bamboo and Git. 

  We develop with Microsoft tools, so just a caveat, although the workflow could apply to anyone, just wanted to give you a heads up in case you come from the world of linux and want to stop reading now :-).

Standing on the shoulders of others

First I want to give thanks and credit to a couple resources.  The following links were invaluable for me;

• This post over at nvie.com described a branching model that is close to ours.
• Understanding tracking and remote tracking branches was cleared up for me by this post over at gitguys.com

Our Git workflow

Here is a picture to get us started.

Figure 1

feature branches

• We create a new feature branch for each issue we work.  So whether the issue is a fix or improvement we create a new branch.  Our feature branch names come from our issue tracking system, Jira.   An example feature branch name would be web-11.
• The feature branch is always created from the work branch.
• It is imperative that our features are given the name of the issue key from Jira.   When we commit to our local repositories we have a pair of Git hooks that update the commit message to contain the feature name and to update a database with commit information. This information is used for our build process.
• After a feature moves to production, the feature branch is deleted.

work branch

• The work branch is what we branch off of to create new features and fixes for our code.
• No one ever commits to the work branch nor do we merge the work branch into any other branch.
• The work branch is basically the prod branch.  But we didn't want anyone doing something accidently to the prod branch so the work branch was created.
• Anytime the prod branch is updated we merge the work branch with the prod branch.

dev branch

• The dev branch is merged with a feature branch when we want to test our feature on our development environment.
• Their are no restrictions on which feature branches can be merged into the dev branch.
• The dev branch is never merged into any other branch.    It is just used to build to our development environment.

qa branch

• The qa branch is merged with feature branches that are intended for sprint or release cycle.   
• The qa branch has features merged into it.   
• Once a feature makes it to qa, if we have an issue with the feature developers can work directly in the qa branch to fix the feature.  It didn't make sense to force the developer to fix their code in the feature branch and then merge it into the qa branch.  The extra step is not needed since the feature branch will be destroyed after the feature is in production.

 prod branch

• The tip of the prod branch is always what is in production.   
• The prod branch is always merged with the qa branch.  
• After a code release we tag the prod branch,  release.3.20.2013 is an example tag.

 What about a hot fix?   Sure our code breaks in production from time to time (well not my code, but the code of others on the team :-) ).   So how do we handle this situation?

We create a hot-fix branch (example, hf-web-33) off of the prod branch.   We then deploy the hot-fix branch to our qa environment.  Once the hot-fix feature passes and is moved to production we merge the hot-fix branch into prod, qa, dev and work branches.   If someone is working on an existing feature branch that might be impacted by this hot-fix we have them merge the hot-fix into their branch.

Advantages of this workflow

• Remove feature branch dependency:
• When we work on features doesn't always coincide with the features that the business wants to be put into a production release.    For example,  assume you have five features ready for the business to test.  But the business only wants to move three features into qa for testing.   What if one of the three features they want was created off of a feature branch of one of the features that they don't want?     This would mean you would have code dependencies to move the three desired features.   You would then be forced to move four features.  But the fourth feature could take longer to test then was originally desired.  By forcing all developers to create new features off of the work branch we remove this dependency
• By using our issue key as our feature name we have streamlined our build process very effectively.

Disadvantages of this workflow

• You get tons of feature branches!  You have to manage the deletion of the feature branches.
• You do spend time switching between branches, which can be hard for someone coming from VSS or TFS to get use to.

   This post is getting a little long. so I have added part II which discusses our build process.

  Thanks for your time!