Git Flow Tutorial Part 1 - What is Git Flow

Git Flow is a set of guidelines developers can follow when using version control. It is often referred to as a “Branching Model” for not only Git, but for all methods of version control. Please remember, that Git Flow is not a set of rules that you have to follow. It is actually guidelines for your version control which are not set in stone.

How it works

You code base needs a central repository. All the developers in the team completed their work locally. Once they have completed their work and feel it is ready for testing, they push their branches. There are two main branches at all times which are used to record project history, Master and Develop. Develop serves as an integration branch for features. This leads to develop being the unstable branch. Master branch stores the official release history. This makes it your stable branch.

Creating a feature

Let's imagine a developer named Jane. Jane would like to create a new feature. The following is a set of steps Jane should follow when creating a new feature.

  1. Jane needs to start working on a new feature.

  2. Jane will pull the latest copy of “develop”.

  3. Jane will fork “develop” and create her own “feature branch”.

  4. Jane will commit her work to this “feature branch”.

  5. When Jane has completed and tested her code, she will merge her “feature branch” into “develop”

Release Branches

Lets imagine a developer named Dan needs to create a release branch. The following is a set of steps Dan will take to create his release branch.

  1. Release branches are created by forking “develop”.

  2. Senior Developer Dan will create a “release branch”.

  3. The “release branch” will contain a pre-determined amount of features.

  4. The “release branch” should be deployed to a Staging server for QA Testing.

  5. Any bugs, needs to be addressed on the “release branch”.

  6. The “release branch” will have to be merged back into “develop” as well as “master”.

  7. You should then tag “master” with a version number.

Managing Hotfixes

Hotfixes are defined as minor fixes to the project. If something needs to go to the Q.A team for testing, in my opinion I would generally not consider this to be a hotfix. A perfect example of a hot fix, is fixing spelling errors in copy. The following is list of steps you should take when creating a hotfix.

  1. Fork “master” to create a new “hotfix” branch.

  2. Commit code to the “hotfix” branch.

  3. The “hotfix” branch, once tested, must be merged into “master” and “develop”.

  4. The “master” branch should be tagged again and deployed.

Creating a "hotfix branch" when you have an open "release branch".

You need to make a "hotfix", after you have already created a "release branch". There may be occasions you have a release branch open that is still with the Q.A team and you need to create an urgent hotfix. Below are the steps you need to follow when you find yourself in this scenario.

  1. You should create your "hotfix" branch as described above.
  2. Once you have completed your "hotfix", you should merge it back into "develop" and "master", as described in the video.
  3. You also need to merge your "hotfix" branch into your "release" branch. This is to ensure your release branch has the latest stable code.

Arrow Icon