This article deals with a model of work with Git branches called git-flow. It was introduced by Vincent Driessen in his article “A successful Git branching model” and is used in different variations. The general scheme of the model is as follows:
Let’s сonsider the scheme in detail.
To make the work with this model easier a handy set of extensions was created (it is available for free here). You also can install it simply by entering the following command in the terminal:
apt-get install git-flow
We will use this set in our examples.
First, we need to create an empty repository. This can be done by typing the following command:
git flow init
After this the user can select the templates for naming branches:
No branches exist yet. Base branches must be created now
Branch name for production releases: [master]
Branch name for "next release" development: [develop]
How to name your supporting branch prefixes?
Feature branches? [feature/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? 
You can safely use the default values here and just go through all the points by pressing Enter. However, if you intend to use these values from the very beginning, you can add an extra key to the command:
git flow init -d
There are two main (master and develop) and several additional branches in git-flow model. Let us take a closer look at each of them separately.
This branch is for a stable working code that can be deployed to a production-server. No actions are performed in this branch and it is just merged with Hotfix and Release branches. Master is generated automatically after repository is created.
The whole code that is being prepared for the next release is placed here. However, the whole functionality concerning future releases should not be here.
This is the name of the functional branches, where the functionality is divided into tasks. Each functional branch is created separately and is merged only with the develop branch after the task is completed. This process is automated and can be done by one command:
git flow feature start test
According to the selected naming template a feature/test branch will be created.
After the functionality is implemented you need to merge this branch with develop. It is very easy to do:
git flow feature finish test
The above mentioned command will merge the feature/test branch with develop and then remove it. Functional branches exist only locally in general, but they can also be added to a remote repository if a lot of people have to work simultaneously on this functionality. This can be done in such way:
git flow feature publish test
The life cycle of the functional branch lasts only during the period of task’s realization. Then you can remove it from the remote repository using standard git-tools.
Once the ready or nearly ready functionality is committed into develop branch you can begin preparations for release. This is the last branch before merging with master. Here some little changes in functionality can be made or some bugs can be fixed. It is forbidden to add a new big functionality to this branch, and all the commits should be transferred to the develop branch. After branch of release v.1.0 is created, it is possible to merge the changes concerning the next release (e.g. v.2.0) with the develop branch.
The beginning and end of the work with the release branch goes similarly to the functional branches:
git flow release start v.1.0. git flow release finish v.1.0.
If the master branch has a bug that needs to be fixed immediately, one can use a hotfix branch. Commands for working with correcting branches are also similar:
git flow hotfix start git flow hotfix finish
This branch allows the development team to continue the work in the develop branch while one developer fixes the bug in the hotfix branch. Being fixed the branch is merged with master and develop. However there is a thing to consider: if at the time of correction the develop branch had already been stable and there was a release branch, the changes will be merged with the release instead of develop.
Git Flow is a model that allows the development being implemented by team using the power of Git. Developers can work over tasks both individually and in groups without disturbing each other. Apart from this there are only two main branches: master and develop, throughout the whole development life cycle. That’s why there is a permanent order in the repository, as all other branches exist only temporarily. This model is simple and clear, and utilization of the automation extension described earlier in this article makes it very easy to use.