GitFlow: A tool to simplify a project’s workflow, collaboration & SCM in Git

Introduction 

Usually, when one is working on a project which has a lot of contributors, it can become challenging to manage (or track) different stages of the project’s code & it can also become challenging in terms of branching if there’s no predefined structure (or workflow) as far as the creation of new branches (& their respective purposes) is concerned. This is where GitFlow can be used.

Working on Features 

GitFlow is a tool (or can be said to be an extension of Git) that provides an adequately structured workflow for better source code management.

Since GitFlow is a tool, we need to install it, after which we can start using it.

Installation

1. Linux
   • sudo apt update
   • sudo apt install git-flow
2. macOS
   • brew install git-flow
3. Windows
   • https://gist.github.com/ilyar/11190988

Setup before using GitFlow

1. Before even using GitFlow, we need a repository (initialized by Git).
2. Once we have a repository, we must initialize it with GitFlow (using the command given below), after which we can start using various commands provided by GitFlow.
   • GitFlow initialization command -> git flow init
   • On executing this command, the user is asked a bunch of questions (such as what should be the prefix for a feature branch, etc).
   •  Usually, we use the default names.

Workflow

In the workflow provided by GitFlow, the following branches are mainly used –

1. master
2. develop
3. feature/<feature_name>
4. release/<release_name>
5. hotfix/<hotfix_name>

We start with a master & a develop branch where the master branch contains the production codebase & develop is the branch from which developers Checkout & work on the features that are typically a part of an upcoming release.

NOTE: master & develop branches are always in sync.

1. Starting a new feature
   • In order to start working on a new feature (which is generally part of a production release), we can use the below command – git flow feature start <feature_name>
   • On executing this command, the following happens –
     1. A new branch is created, which is checked out from the ‘develop’ branch.
     2. Our current branch is changed to the newly created ‘feature/<feature_name>’ branch.
2. Finishing a new feature
   • Once the developer has finished working on the feature, the feature can be finished/closed using the below command –
   • git flow feature finish <feature_name>
   • On executing this command, the following happens –
     1. The feature branch gets merged into the development branch.
     2. The feature branch gets deleted.
     3. The developer’s current branch gets switched back to the development branch.
3. Publishing a feature
   • Let’s say there are two developers (including us) working on the same feature, but the other developer needs our changes to finish the work on the entire feature. In such cases, we can publish the feature to the remote server so that the other developer can use our changes. To do so, we use the below command –
   • git flow feature publish <feature_name>
4. Getting a published feature
   • For the other developer(s) to get/receive our published feature, the below command has to be executed –
   • git flow feature pull origin <feature_name>

Working on Releases 

• Once enough features (that can be considered a “release”) have been merged (or accumulated) into the develop branch, we can create a “release” branch. After the “release” branch is created, it is tested thoroughly & if any bugs are found, they are fixed in the branch itself. Once everything is deemed acceptable, the release branch is merged with the master branch & develop branch (since these two branches are always supposed to be in sync) & then the release branch is deleted.
  1. Starting a Release
     • In order to start a release, we use the below command –
     • git flow release start <release_name>
     • Executing this command will do the following –
       1. Create a new release branch called release/<release_name>
       2. Check out the newly created release branch.
  2. Finishing/Closing a Release
     • In order to finish a release, we use the below command –
     • git flow release finish <release_name>
     • Executing this command will do the following –
       1. The release branch will be merged with the master branch.
       2. In the merge with the master branch, the release will be tagged with a release number (something like v1.0.0).
       3. The release branch will be merged with the development branch as well.
       4. Finally, the release branch will be deleted.

NOTE: As we can see, executing one command (for finishing the release) performed four different operations (a. to d.). This is the benefit of initialising the repository with GitFlow.

Working on Hotfixes 

In case some bugs arise in the production codebase (in the master branch), which might be critical & might need some immediate/quick action, we can create hotfix branches.

The hotfix branches are checked out from the master branch, wherein, whatever bug that had occurred in the production codebase is fixed, after which, the changes are merged into the master (with an updated version tag number) & the develop branch.

1. Creating a Hotfix
   • In order to create a hotfix branch, we use the below command – git flow hotfix start <hotfix_name>
   • Executing this command will do the following –
     1. Create a new hotfix branch called hotfix/<hotfix_name>
     2. Check out to the newly created hotfix branch.
2. Finishing a Hotfix
   • In order to finish a hotfix branch, we use the below command – git flow hotfix finish <hotfix_name>
   • Executing this command will do the following –
     1. The hotfix branch will be merged with the master & the develop branch.
     2. Finally, the hotfix branch will be deleted.