Git Workflow

Overview

About a year ago my team of developers migrated our application’s source code to git.  During this transition we did a lot of research to help prepare for the move.  Our main concerns were around workflow.  The team was ready to become freed from a lot of the pain they were used to while working with TFS (e.g. how difficult it is to create a feature branch).  Recently we revisited our workflow and made some improvements with how we use git.  Additionally, we moved over to gitlab (we were previously using gitblit) and started taking advantages of the features gitlab has to offer.  This article attempts to describe our workflow in it’s current state.  Maybe a similar workflow will work for your team.

Branching Strategy

The project will use two main branches; master and develop.  The master branch reflects a ‘production-ready’ state.  The develop branch reflects the latest delivered development changes for the next release.  Feature branches are also created when development on a new feature begins.  These branches are created off of develop.  While the new feature is being developed, it may get rebased with changes made to develop on a regular basis.  Lastly, when the new feature is complete, it is merged back into develop.

Two important rules to follow

1. There will only be one level of feature branches (never create a feature branch off of a feature branch)
2. Communicate frequently with other devs who share the same feature branch as you

Branching Details

• origin/master
  • to be the main branch where the source code reflects production-ready state
  • tags would be used as identifiers for releases
• origin/develop
  • to be the branch where source code reflects the latest delivered changes for the next release.  This branch is where our continuous integration environment builds, runs tests, checks code tests, deploys, etc.
    
• origin/{feature branch}
  • Branch off of origin/develop which represents a new feature being developed
  • Branch names should include the story name and number
  • Rebase your feature branch with changes in origin/develop regularly
  • Create a merge request and discuss your changes with the team before merging the feature branch to origin/develop
  • Feature branch will be deleted once it’s merged back to origin/develop.  This is the responsibility of the developer who created the feature branch.
    
• origin/{hotfix branch}
  • A hotfix branch may be created off of master for special circumstances.
  • Hotfix branches are deleted after the changes are deployed to production and merged to master.
  • A hotfix branch should be short lived (one day or less)

`New Feature` Lifecycle

1. Team is assigned a new feature to work on.  A new feature branch is created for this story.  In the event that we are working on a large feature, multiple feature branches may be created.
2. Changes related to the new feature are worked on in the feature branch.  If there is an operations support issue (bug) that needs to be worked on while this feature work is being done, then that work is done directly in the develop branch.
3. During the life of the feature branch we may rebase it with changes happening in develop.  We typically rebase no less than once a week.
4. Once the development of a feature is complete a merge request is created and other devs have an opportunity to review, comment and request changes to the feature branch.
5. Once the merge request is approved by the team the feature branch is merged into develop.  The scope of the features branch changes are hopefully small enough so that we can complete them within a week or two.
6. We have a Jenkins server which polls our develop branch for changes.  When changes are merged into develop our unit tests are ran.  Hopefully there are no test failures, but if there are they are fixed immediately.
7. Once all tests are passing in develop we are then able to deploy the changes to other lower environments and eventually production.  This is done via Jenkins as well.
8. After the changes are deployed to production we merge out changes to master.
9. (Optional) In the case where a bug is found and needs to be prioritized higher than other changes already in develop, then a hotfix branch is created.  The fix for this bug is then checked into the hotfix branch deployed to production.  The hotfix branch will get merged to master and develop may be rebased with that fix.

Rebase vs. Merge

There has been numerous discussions concerning when to rebase and when to merge.  There are many other blogs that review the differences between these two commands so I will not go into much detail there.  What we basically decided is similar to what other teams are doing.  First, everyone should be setup to do a rebase when they `pull` changes from origin.  This can be done in one of two ways; `git pull –rebase` or add `autosetuprebase = true` in your .gitconfig.

Next, when creating a feature branch, it is good practice to make sure you keep your feature branch up to date with changes going on below you (develop). You can do this by doing frequent rebases.  This is preferred over merging your changes into the feature branch from develop.  Once the merge is complete you may need to do a `git push –force`, this is the ONLY time it is acceptable to force a push to origin.

Finally, when a feature branch is ready and you confirmed that ALL test cases pass on your feature branch, you will want to `merge` your changes into develop.

• dvcs
• git
• source control