A Brief Guide to Git Flow

For the past 3 years I have been using the Git Flow model when it comes to version control. Or at the very least trying to.

What is Git Flow?

Well Vincent Driessen explains it very well in a post that he wrote over 5 and half years ago and it can be easily summed up in the diagram at the very start of his article.

I will let you read that article to get a good explanation of it. The idea is that you have a master branch that has nothing more than the latest stable release (which is the latest tag) and a develop branch that has all of the latest features and code that are yet to be released. You then have feature, release and hotfix branches that are used for various purposes.

Again, it is pointless me reciting what the article already says so read that for more information and then come back here.

But then why write this article?

Well, not only was it to inform of the existence of this model, but also to help you implement it. There is a very handy tool that automatically does the branching and merging for you!

To install simply:

apt-get install gitflow

There are installation instructions for other platforms here.

Now you have to set up your Git repository to be ready for it.

If you are starting a new one from scratch then it is easy. Do your initial commit on the master branch. Then make a new branch from 'master' and call it 'develop' (or development or bananas, whatever helps you know that it is the develop branch).

If you are changing an existing one then you will need to be more careful. Since this is meant to be a 'brief' guide, I won't go into detail of how you set up your master and develop branch but you will need to do this before you continue. I will write up a follow up article that goes into some more detail on that.

Once you have your repository set up, go to it and do:

git flow init

You will be asked some questions. The first is the name of the 'master' branch, then the name of the 'develop' branch. If you named your branches master and develop then you can just hit return for both of these as that is the default.

You can also hit return for the rest of the questions also. What they are asking is to put in front of the branch name that it automatically makes. The defaults are the clearest.

Thats it, you are set to go.

So to start a new feature you simply do:

git flow feature start nameOfFeature

This automatically branches from the develop branch called feature/nameOfFeature.

When you are finished simply do:

git flow feature finish nameOfFeature

This will automatically merge feature\nameOfFeature back into develop and delete it locally (you have to delete the remote one yourself unfortunately).

The same applies for hotfix and release. You should put the version number for these for example:

git flow hotfix start v1.0.1

This is because when you run finish it will automatically tag it for you.

hotfix automatically branches from the master only (as described earlier) and merges back into master and develop when you finish (as well as tagging the master after the merge.

release automatically branches from develop and merges back into develop and master when you finish (as well as tagging the master after the merge).

Gitflow will also prevent you from starting more than one release or hotfix at any time.

Why I Love Git Flow

Hopefully I have shown how easy it is to implement the Git flow workflow for your projects. I really like it because, to me, it makes the most logical sense! Especially when you have a big team working it on.

It allows you to be able to have multiple features being worked on at once. It allows for beta testing when you do 'release' branches and it makes sure that there is always a branch with the latest stable release from which hotfixes and patches can be created from.

The only downside is if you are supporting multiple versions of software. You either have to have 2 seperate repositories or you have to start making branches manually (which isn't actually that hard). But the workflow as a whole doesn't really factor in multiple master branches that would be needed.

© 2012-2022