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 separatefeaturebranches. - 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.
After this action 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
masteranddevelopbranches, 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
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
masteras well as intodevelop, to make sure the bug doesn't slip into the next release, again. - The
hotfixis 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 easily.
I found it on Daniel Kummer's git-flow cheatsheet repo. Check it out in his repo.
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?
Find me around web 🕸:
- 💻 Visit my Website
- 🌟 Check out my Substack
- 😸 Check my Repos on GitHub
- 🦊 Check my Repos on GitLab
- 📦 Check my Packages on NPM
- 🔗 View my Profile on LinkedIn
- 📝 View my Blogs on Dev.to
- 😜 Follow me on Instagram
- 📚 Check out my Goodreads Profile
- 📪 Contact me Here
Oldest comments (26)
Nice article, but as always with this kind of tool, I'm very sceptical about it's actual usefulness. It sounds a lot like a very small improvement for someone who knows git already and a very good excuse not to get to know it better for everyone else.
Git-Flow integrates very easily into your existing Git. You dont have to change anything, only your workflow will be optimized. It will also improve your project structure. But that doesn't mean you have to always use it in all of your projects.
But yes you can always give an excuse for not learning a new thing.
Btw thanks a lot for your reply...
It occurs to me that you can do all of the above quite easily with standard Git commands. If it's an approach and a philosophy then fine, but I don't think I'd need a specialized tool or commands per se.
Yes...as I said in the post...git-flow is not a replacement for standard git commands...it just combines some standard commands and automates some tasks to make your workflow more optimized...
You can do all these manually...Git-flow just makes it easy for you
You would think, but experience has taught me that on a team with other programmers, a standardized workflow is a really good idea, approaching absolutely necessary. Some people need help remembering how to do each step in a workflow, and well-written scripts can help avoid mistakes for everyone. And it's much better to use community-tested tools like this than write your own, unless you really are a master at git and have a special requirement that couldn't be met just by configuring your repo and/or adding hooks and using a well-tested tool like this one.
It also helps if you realize that Git Flow is a standard workflow for Git, and these scripts implement it for you.
I like git-flow, however I always seem to run into the same problem. When feature requires client or external stakeholder feedback before it could be considered done, where does that fit? External feedback could come back in minutes or months and doesn't make sense to block a release.
That entirely depends on the client...
Thanks for your reply...😊
That's on the stakeholder, and you need to set a deadline for their feedback. If feedback is still absent at the deadline, and the PR passes tests, (dev team) review, and definition of done, you push the release without them. If you never got the feedback required to complete, you make a decision on what to do with it (keep the branch alive while rebasing, save a diff, or just kill it, and close the issue as stale due to no feedback).
The key in either case is to document your attempts to get feedback and the stakeholder's failure to provide it (CYA).
Maybe it's because I am viewing this as an agency, but none of that seems possible.
The definition of done requires the client's approval as something cannot be released to a client's site/app/service without their approval. Going back to a client with "The change needs to be re-tested " when they finally provide their feedback is a good way to end up with unhappy clients.
I wasn't speaking specifically to clients (many stakeholders are internal, and I've worked numerous projects where all of them were), but even with external clients, you need language in the contract for cases where they are not responsive.
And sure, it is often the case that the feature just doesn't get pushed (but the client is still billed for your time) if they fail fulfill their obligation as a stakeholder.
And again, CYA applies universally.
I've observed that client feedback requires them to see a working demo. And so to solve that problem, we do weekly demos. I really encourage daily demos (doubling down on the principle of short feedback loops to help me mitigate alignment issues).
Then the problem becomes, how do I deploy this version so that I can demo it. This is where having a Developer Enablement Platform (fancy word for k8s or Cloud Foundry or some Platform as a Service that lets developers deploy versions from their machine or pipeline) helps enable this. I fully acknowledge that this can be hard, politically, technically and financially :(
BTW, I've used glitch.com as a way to demo.
I recommend fully and completely against git-flow:
Research shows effective teams deploy multiple times a day, but git-flow discourages that by adding the “develop” branch, and by introducing feature branches and hot fixes. Those concepts are all performance-negative.
Science shows we should aim to have a single main branch that is always deployed, and just commit to that. Any branches you create must live for a maximum one day, preferably much shorter. Don’t worry about hotfixes either, just land changes to main branch. Instead featureflags become the way to control what and when things are released
git-flow is a tool and workflow that can look impressive, but it actually puts up more barriers and adds more deploy latency where science suggests we should aim for less.
The science I refer to is DORA and Accelerate book by Dr. Nicole Forsgren.
That's your opinion...and its fine... everyone doesn't like the git-flow...
But forget about feature branch and hotfixes....even if you only have a develop branch...it keeps your deployed code more error and bug free...
Thanks a lot for your reply
I second that: georgestocker.com/2020/03/04/pleas...
As with all of these new or different techniques or approaches you need to begin by asking yourself: what problem am I trying to solve ?
If the way you work right now is fine and there is no problem really, then just stick with what you're doing and don't jump on the latest bandwagon because it's "hipster" or because everyone does it.
So is Gitflow good or not - as always, "it depends" ... but the moment someone offers me a "solution", then the first thing I ask: okay cool, but what was the problem again ?
If you're already doing Continuous Release, I agree Gitflow probably isn't going to help your team.
However, not everyone is doing or can do Continuous Release, for any number of reasons. Those teams can often be helped by defining a standardized workflow that everyone follows. For instance, I work on a simulation for a government customer that has integrated test dates and milestones we have to follow. So we have a fielded build we have to support with hotfixes, a future build of that line for the next integrated test, and a future build that adds support for whole new assets that will require a lot of early development before it's ready to be deployed that we can't hold up the next build for. I've been trying to suggest that my project adopt Git Flow or a modified version of it because that's still WAY better than what we're doing right now, which involves lots of dev and release branch cross-merging instead of merging selectively and consciously from hotfix and feature branches.
As an aside, though, thank you for actually backing up your "research/science shows" statements with the source. I was going to accuse you of using weasel words there, but now I have a book to check out. :-)
If there's a long-lived develop branch, what's the point of having the master branch anymore if it's never used to build the published artifact from?
What's your recommendation for when multiple people are adding separate features to a single repo and there's a deployment happening on Thursday but only 1 feature is ready for deployment and the others are still being worked on?
You didn't understand the workflow properly. The develop is there to save the master branch from any unwanted bugs. It works like a guard in front of the master.
And when ready the develop branch will be merged with the master.
And when several people are working on a repo... everyone will work with their own separate feature branch. When the feature is ready they will finish that and it will get merged to the develop, which will then be merged to master.
And master is the branch that is used to deploy your code.
Who merges from develop to master?
The designated integrator, which might be one person or a team. There might be testing required before, etc.
My apologies. This post is about the tool. I got caught up in the underlying branching strategy that it supports, which touches a smallish nerve.
Thank you Soumya for writing this article. I really appreciate being reminded of past strategies and challenging the decisions that we made in the past to see if they are still valid in the present.
Yeah, it can kind of be confusing if you don't read up about git flow first. This article is more about the support tool/scripts.
The releases sit on the master branch as tags. There is no standalone release branch. The dev branch is more like a dev and test branch that you release from. But any new hotfixes or new, separate releases might be branched off of master.
This looks like the same gitflow by Vincent Driessen.
He didn't claim it wasn't. If you read the README for the extension he's recommending, the author, Peter Vanderdoes, credits Vincent Driessen and links to his article.
There are some criticisms below of the Gitflow model. These criticisms are not new. Scott Chacon explained 9 years ago why it wasn't the right choice for GitHub's continuous release flow and explained the GitHub workflow:
scottchacon.com/2011/08/31/github-...
And if you go back to Vincent Driessen's original blog post introducing it, you'll note that he's made an update about why even he doesn't think it's the right fit for Continuous Release, with the reminder that context matters:
nvie.com/posts/a-successful-git-br...
There is a bugfix branch which will be created from develop branch.