Project – New Git Branching Model

I found a better Git branching model.  Currently, a branch is created for the development release series.  For example, branch0.5 was created for all the 0.5.x versions (0.5.0 through 0.5.3).  Once this development series was completed, the branch was merged back to the master branch.  Since there were no other changes on the master branch, the pointer to master was simply moved from 0.4.6 (the last of the 0.4 development series) to 0.5.3 - what is known as a fast-forward merge.  In the end though, the repository is just a long row of linear commits.

The new Git branch model is detailed in this blog post.  I'm going to adopt this branching model.  The main development branch will be named develop, which will replace the branchX.X branches that has been used for development.  When development is ready for a release, a releaseX.X branch will be created from the develop branch.  There will be at least one commit used for updating the version number, and possibly another to do minor clean up (like fixing comments), plus any for possible platform related bug fixes discovered during testing.  This will replace the "updated files for release X.X.X" commits just before a release.  If testing goes well (on all platforms), then this branch will be merged to master and tagged for the release (as vX.X.X).

When a new feature, function or change is being added (what is called a "topic"), a topic branch will be created off of the develop branch and will be named for the topic.  This will more clearly state what is being developed (branchX.X states nothing except the release series).  When the topic is complete, it will be merged back to the develop branch.  If for some reason the topic doesn't work out, then the branch will abandoned and an empty commit will be made with the reason for the abandonment.  These topic branches will allow more when one topic to be worked on at a given time.

This model also allows for hit fixes to the master branch, where a hotfix-X.X.X branch will be created for the fix (which includes the proposed hot fix version number).  Once complete, the hot fix branch will be merged backed to the master branch, and it can be merged to the develop branch as needed.

As the blog post explains, all merges will use the no-fast-forward option (--no-ff), meaning that Git will make a merge commit showing the branch being merged instead of just moving the branch pointer.  Using this option will allow it to be cleary seen where the branch started and where it was merged.  With the current model, there is no way to see where the branch originally started, only where it ended up (assuming it isn't deleted, which is why the older development branches were not deleted).