Kiến trúc Git flow - repository operations model

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.

1. Master

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.

2.Develop

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.

3. Feature

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.

4. Release

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.

5. Hotfix

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.