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
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 separatefeature
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.
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:
- It pulls from the remote repository to make sure you are up-yo-date.
- Then, the release is merged back to both
master
anddevelop
branches, so that your production code as well as all feature branches will be based on the latest code. - A release commit is tagged with the release's name (
1.1.5
in our example). - 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:
- The changes are merged both into
master
as well as intodevelop
, to make sure the bug doesn't slip into the next release, again. - The
hotfix
is tagged for easy reference. - 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.
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?