Advantages of Git-flow over standard git commands

Advantages of Git-flow over standard git commands

In this post we'll look at a git workflow called Git-flow, and discuss why you should use it over the standard git commands.


What is git-flow?

git-flow has become quite popular in recent years, as it provides handful of extra commands. It automates some tasks for you that you'll need to do manually if you are using standard git commands.

git-flow is by no means a replacement for Git. It's just a set of scripts that combine standard Git commands in a clever way.

Install Git-flow

Windows:

For Windows users, Git for Windows is the recommended method. Follow the instructions on the Git for Windows homepage to install Git for Windows. As of Git for Windows 2.6.4, GitFlow (AVH edition) is included, so you're all done.

Linux(Ubuntu 18.04):

git-flow AVH edition is packaged with Ubuntu. You can install the last version of git-flow AVH Edition using the following command.

$ sudo apt-get install git-flow

For other linux distros follow these instructions

Mac OS X:

For Mac OS installation follow these instructions

Using Git-flow In Your Project

It's totally up to you to use special git-flow commands and normal Git commands in this repository side by side.

First you have to initialize git-flow in your project using the command git flow init

$ git flow init
Initialized empty Git repository in E:/Development/projects/git-flow-tut/.git/
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/]
Bugfix branches? [bugfix/]
Release branches? [release/]
Hotfix branches? [hotfix/]
Support branches? [support/]
Version tag prefix? []
Hooks and filters directory? [E:/Development/projects/git-flow-tut/.git/hooks]

Although the setup assistant allows you to enter any names you like, I strongly suggest you stick with the default naming scheme and simply confirm each step by pressing Enter.

Git-flow Branching Model

Alt Text

The git-flow workflow model needs you to have two branches in your repository.

  • master branch contains the production stable code. You won't commit directly to master, instead will work on separate feature branches.
  • develop is the basis for any new development efforts you make: when you start a new feature branch it will be based on develop.

These two branches remain in your project during its whole lifetime. Other branches, e.g. for features or releases, are created on demand and are deleted after they've fulfilled their purpose.

Alt Text

Feature Branch

Starting a new feature

Let's say you are going to add a payment gateway to your project. So that is a new feature.

Let's start a new payment-gateway feature

$ git flow feature start payment-gateway
Switched to a new branch 'feature/payment-gateway'

Summary of actions:
- A new branch 'feature/payment-gateway' was created, based on 'develop'
- You are now on branch 'feature/payment-gateway'

This action creates a new feature branch based on 'develop' and switches to it.

Finishing the Feature

After all your hard work is done and committed, its time to finish the feature.

$ git flow feature finish payment-gateway
Switched to branch 'develop'
Updating 6bcf266..41748ad
Deleted branch feature/payment-gateway.

Git-flow deletes the (now obsolete) feature branch and checks out to the "develop" branch.

Release Branch

Start a Release

When "develop" branch is ready for a new release, then start a release using the git flow release command. It creates a release branch created from the 'develop' branch.

$ git flow release start 1.1.5
Switched to a new branch 'release/1.1.5'

Finishing the Release

When its time to finish our release use the following command

$ git flow release finish 1.1.5

This action performs the following tasks at once:

  1. It pulls from the remote repository to make sure you are up-yo-date.
  2. Then, the release is merged back to both master and develop branches, so that your production code as well as all feature branches will be based on the latest code.
  3. A release commit is tagged with the release's name (1.1.5 in our example).
  4. Deletes the release branch and checks out to develop.

Hotfix Branch

These are for the mischievous bugs that might appear even after thorough testing in a release.

Starting Hotfix

$ git flow hotfix start missing-link

hotfix is quite similar to release branch. Just like with a release, however, we bump up our project's version number and - of course - fix that bug!

But we need to remember one thing that Hotfix is based on the master branch whereas release is based on develop branch

Finishing Hotfix

$ git flow hotfix finish missing-link

The procedure is very similar to finishing a release:

  1. The changes are merged both into master as well as into develop, to make sure the bug doesn't slip into the next release, again.
  2. The hotfix is tagged for easy reference.
  3. The branch is deleted and "develop" is checked out again.

So now's the time to build / deploy your product.

As a bonus here's a great illustration for you to remember the Git-flow commands better.

Alt Text

I found it on Daniel Kummer's git-flow cheatsheet repo. Check it out in his repo and also follow me on Github & Dev.to if you like my writings.

Thanks for reading my blog. Hope it helps you and your team to be more productive.

Let me know if you are already using Git-flow or planning to use it?