Git Branching Strategies

My name is Andrii Vovk. I am an Android Developer at AllStars-IT Ukraine. In this article I want to talk about Git branching strategies.

Using Git version-control system is standard in the industry of software engineering.

When starting development, it’s a good idea to define Git branching model for a team and document it – if the teammates follow clearly defined rules, it saves time and keeps their minds clearer for creativity.

Well-known Git branching approaches in fact derive from the famous “git-flow” by Vincent Driessen and more or less simplify that fairly comprehensive strategy.

Scott Chacon’s “GitHub Flow”, as well as “git-flow”, is designed for large teams of 15 and more developers with the difference that meets the needs of teams which deploy continuously while the “git-flow” process is built mainly around the “release” events.

So, the good practice is to take into account your deployment strategy when choosing the branching model.

Another point is the size of your team: the smaller is amount of employees who work on the same project at the same time, the simpler branching strategy can be used (but not oversimplified – even if a single developer works on a project, at least two branches should be used in order to keep the master branch stable, rather than having there part-completed features that may cause issues).
In mobile software engineering field, there are commonly 2-5 developers working on a project for each platform (usually Android and iOS).

Here are several rules that I would highlight as the main ones when defining Git branching strategy for such teams:

0. When working on any feature or bug fix, descriptively named branch should be created.

1. Always branch from master, rarely as an exception – from feature branches (e.g. for experiments).

2. When the work on a feature is finished, a branch is merged back into the master.

3. The master branch is always deployable, so features must be finished and thoroughly tested before they are merged in.

4. Pull requests should be created to get code review/QA on the change before it merges.

5. After an application is released, the master branch may contain currently deployed version, and the develop branch may be introduced as the main one for the development of the next version before it’s is being released.

All of feature branches must be merged into develop branch before merging develop to master. An alternative is to use tags to mark your releases when you make them.


I hope that these tips can help to improve your teamwork and wish you happy engineering!


Sources: – “A successful Git branching model” by Vincent Driessen – “GitHub Flow” by Scrott Chacon – “Choose the right Git branching strategy” by Lorna Mitchell

Leave a Reply