Gitflow: an introduction

The Context

In a few words, Git is a version control system, an essential tool to handle the life cycle of the development of an application.

So far so good, classic Git, but problems start showing up when handling teamwork: you and your team might decide to just work on the main branch of the project and create some secondary branches on special occasions, but what happens when there is a lot of work or several people must work in the same function at the same time?

What is Git-Flow

When working as a team, it is necessary to define conventions or good practices so that everyone knows how to work together. GitFlow is one of many so-called workflows, quite popular for its practicality and relatively quick learning. GitFlow is a branching model for Git; It has attracted a lot of attention because it is very well suited to collaboration and scaling the development team.

 

Key benefits

Parallel Development

One of the great things about GitFlow is that it makes parallel development very easy by isolating new development from finished work. New development (such as features and non-critical bug fixes) is done in feature branches, and is only merged back into master when the developer(s) is happy that the code is ready for release.

We all know interruptions are a bad thing, with this flow if you are asked to switch from one task to another, all you need to do is commit your changes and then create a new feature branch for your new task. When that task is done, just checkout your original feature branch and you can continue where you left off.

Collaboration

Feature branches also make it easier for two or more developers to collaborate on the same feature, because each feature branch is a sandbox where the only changes are the changes necessary to get the new feature working. That makes it very easy to see and follow what each collaborator is doing.

Staging Area

When the development is finished, these changes gets merged back into the develop branch, which is a staging area for all completed features that haven’t yet been released. So when the next release is branched off of develop, it will automatically contain all of the new stuff that has been finished.

HotFixes

GitFlow also supports hotfix branches - branches made from a tagged release. You can use this branch to make a hotfix (critical bugfix) and its safe because all this hotfix branch will contain is ONLY your hotfix. There’s no risk that you’ll accidentally merge in new development at the same time.

Now lets see how it works

You have probably already seen this image or a similar one when searching the term Git-Flow on the Internet:

A picture is worth a thousand words, or in this case a couple thousand more

It seems and is complicated at first glance, but when you know the different branches used and the reason for their existence, you will see that the handling is quite logical.

Branches

As we saw in the image, Git-Flow uses several branches to organise the development:

• master
• develop
• feature
• release
• hotfix

master & develop

If you have used Git before, you will be familiar with the master branch. In this new context, this branch is "untouchable", no one from the team should make any changes directly to it, nor create new branches from it, with one exception that we will review later.

When creating a new project, or when starting to use GitFlow, the develop branch must be created from master, and like master, it will be a "long-lived branch", that is, it will never be deleted and will be parallel to master.

As its name implies, the develop branch serves as the basis for working on all new project features and fixes, which is why it is considered the main branch.

Once all the new project functions & bugfixes have been completed and develop is on a rather 'stable' state, we should merge develop in master.

The master branch should always reflect a 'production' state, so it is important that we do not make changes directly to it, since every time there is a new commit, we should tag it to define the new version and publish it. In this context, the master branch is sometimes referred to as the 'integration' branch.

feature branches

New development (new features, non-critical bug fixes) are developed in feature branches.

Feature/bugfix branches are branched off of the develop branch, and finished features and fixes are merged back into the develop when they’re ready for release

And when its time to make a prod release, a release branch is created off of develop

The code in the release branch is deployed onto a suitable test/UAT environment, tested, and any problems are fixed directly in the release branch. This deploy -> test -> fix -> redeploy -> retest cycle continues until we're happy that the release is good enough to release to public.

When the release is finished, the release branch is merged into master and into develop too, to make sure that any changes made in the release branch aren’t accidentally lost by new development.

The only commits to master are merges from release branches and hotfix branches.

Hotfix branches

These branches are used to create critical(HOT) fixes. These branches are branched directly from a tagged release in the master branch, and when finished we merge them back into both master and develop to make sure that the hotfix isn’t accidentally lost when the next regular release occurs.

Happy coding :)