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.
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.
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.
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
For Mac OS installation follow these instructions
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
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
- 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.
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
$ 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.
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.
After this action
Git-flow deletes the (now obsolete) feature branch and checks out to the "develop" branch.
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'
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
developbranches, 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.5in our example).
- Deletes the release branch and checks out to
These are for the mischievous bugs that might appear even after thorough testing in a release.
$ 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
$ git flow hotfix finish missing-link
The procedure is very similar to finishing a release:
- The changes are merged both into
masteras well as into
develop, to make sure the bug doesn't slip into the next release, again.
hotfixis tagged for easy reference.
- The branch is deleted and "develop" is checked out again.
As a bonus here's a great illustration for you to remember the
Git-flow commands easily.
Let me know if you are already using
Git-flow or planning to use it?