SECRET OF CSS

GitFlow: A Quick Guide. Manage Git branches with ease | by Dieri Ismail | May, 2022


Manage Git branches with ease

Working under source control is a must-have practice for current projects, mainly agile projects. But what’s more important is to put in place a well-defined strategy to manage your source control so you can boost your productivity and meet your milestones.

In this article, I will talk about GitFlow as one of the most famous workflows to manage Git branches.

GitFlow is a novel strategy for managing Git branches. GitFlow strategy deals with two main trunks: develop and master.

GitFlow strategy defines different types of branches that act at different phases of your project’s lifecycle:

  • Development Phase: Developments are done in independent feature branches. The two main actors of this phase are develop and by-feature-branches
  • Pre-Release phase: Preparing the next release is ensured by release branches.
  • Release phase: the only unique actor is master branch.
  • Post-release phase: ensured by hotfix branches.

git-flow CLI is a bunch of macro git commands. They are very helpful when opting for GitFlow strategy.

GitFlow allows you to manage the different kinds of branches at a higher level of abstraction. Let’s suppose that you have a hotfix, called change_api_url, that you need to merge to master and develop. Using the standard git commands, you need to write the following commands:

The same can be done simply using a git-flow CLI:

Another advantage of using git-flow LCI is that the former will recommend you a standard folders structure that align with the GitFlow concepts, and you can customize names for every folder. This is done when you execute the command:

git flow init
1*Lnb0 bQJD1LMJEYC9IAoyw

Referring to the below command result, all the features will be created under the feature/ folder, …

For more information about GitFlow and how to install it, you can go here.

If you opt for basic git commands, I would recommend you to use no-ff option when merging, to keep a clean history and for an easy revert.

Also called main or prod. Every commit to this branch is a production release by definition, so you could configure your DevOps server to automatically launch a new release to the production servers, aka continuous delivery.

This branch reflects always the production-ready state.

Merges to this branch are only permitted from release and hotfixes branches.

It is best practice, to give a tag to every merge into this branch that corresponds to the release number.

Also called integration-branch. This is where any automatic nightly builds are built from, aka continuous integration.

It reflects the next-release development state.

When the develop reaches a stable state ready to be delivered and all the planned features for the next release have been developed and merged from their own branches into the develop. You can decide at this moment to proceed with your next release serenely.

Merges to this branch are accepted from features, hotfixes, and releases.

Also known as topics.

For every new feature, you create an independent branch that you take off from the develop.

This type of branch is used to develop new features for the upcoming to a distant future release.

So once the development of a feature is done and we have taken the decision to embed it in the next release. We first start by merging it into the develop, and then we delete the feature branch.

Unlike develop and master, these branches always have a limited lifetime.

Feature branches should stay isolated from the rest of the branches. They should not accept merges from any other branches. So they reflect only commit related to the current topic.

Features are only merged into the develop.

GitFlow Tips:

To start a new feature:

To publish to remote:

To pull from remote:

To finish a feature:

Once the develop reaches the desired state for the next release, means that develop is stable and contains all the next-release features. We branch off a release branch.

Release branches support the preparation of a new production release. They allow for minor bug fixes and preparing meta-data for your release (version number, build dates, …).

Releases should not accept merges from other branches.

Releases are merged into develop and master. Once done, you should delete it.

Please note, that develop could not accept future release branches unless the next-release branch is branched off.

It is recommended that you name your branch with a version number since git-flow CLI will use this name to create a tag with the same name in the master branch

GitFlow Tips:

To create a new release:

To publish to remote:

To pull from remote

To finish a release:

Don’t forget to push the created tag to the remote

When a critical bug in a production version must be resolved immediately, a hotfix branch may be created from the master from the corresponding tag that marks the production version.

The hotfixes should be merged into master and develop. And as we mentioned earlier in this article, it is always recommended to tag the master commit.

It is recommended that you name your branch with a version number since git-flow cli will use this name to create a tag with the same name in the master branch

GitFlow Tips:

To create a new hotfix:

To publish to remote:

To pull from remote:

To finish a hotfix:

Don’t forget to push the created tag to the remote:



News Credit

%d bloggers like this: