GitFlow : methodology and practice
This post is free for all to read thanks to the investment Mindsers Courses members have made in our independent publication. If this work is meaningful to you, I invite you to join our courses today.
GitFlow is what we call a workflow, a working strategy for Git. There are a lot of others, but GitFlow is one of the most famous. He was thought by nvie. What is the point of using it?
Why is it important to have a Git strategy?
Git is a powerful tool, but is generally misused. We all know a great tool badly used is counter-productive.
In Git's case, it can be in the form of conflicts on every (or almost) commit/merge, data loss (even if you really have to push it for that), etc…
How does GitFlow work?
GitFlow is a list of simple rules based on the branch model of Git.
Here is the basis :
Our project is based on two branches : master and develop. It is strictly forbidden for devs to write on those two branches.
The master branch is the mirror of our production. Thus, we can not push modifications on here directly.
The develop branch centralizes the new features that will be delivered in the next version. You will have to force yourself to not modify it directly.
Three other types of branches are then going to allow us to work :
featurereleasehotfix
Developing features
So, I will be developing on a feature type branch.
git checkout -b feature/<nom> develop
If I develop a new feature, it will logically be applied to the next version, so I will create my branch starting from the develop branch.
I start working on the updated code for the new version.
git checkout develop
git merge feature/<nom> --no-ff
git branch -d feature/<nom>
When I am done, I put the code on the develop branch and delete the now obsolete feature branch.
I prepare a new version for production
I am going to work on a release type branch.
git checkout -b release/<version> develop
I create my branch from the develop branch, so I can run my tests and apply my corrections, while my colleagues are already starting to develop new features for the next version.
If your colleagues already merged some code targeting the next release, you can replace the develop branch name by the hash of the right commit.
git checkout develop
git merge release/<version> --no-ff
git checkout master
git merge release/<version> --no-ff
git tag <version>
git branch -d release/<version>
When all my tests are successfully passed and my new version is ready for production, I push everything on the master branch without forgetting to apply my corrections to the development branch too.
I also create a tag on the last commit of the production branch with my number of version to keep it clear.
Finally, I delete the release branch because it is now useless.
I fix a bug in production
I will be working on a hotfix type branch.
git checkout -b hotfix/<name> master
For this particular case, I create my branch starting from the mirror of the production because I don't want all of my features of the development branch to be in production when I fix a simple production bug.
git checkout develop
git merge hotfix/<name> --no-ff
git checkout master
git merge hotfix/<name> --no-ff
git tag <version>
git branch -d hotfix/<name>
My bug being fixed, I need to apply it to the development and production branches. Once again, I version with a tag on my master branch and delete my hotfix branch.
GitFlow, the overlayer
You find everything you just read awesome, but hard to execute on a project? I get it. When you are just getting started, it is hard to remember the branches names, the starting points and target of each branch depending on the situation you are in.
Thankfully, GitFlow's creator thought about you and developed an overlayer for Git to simplify the process. It gives you new high level commands such as :
git flow init : to initialize Git and GitFlow in a project.
git flow feature start <name> : to start developing a new feature.
git flow feature finish <name> : to end the development of a new feature.
git flow release start <version> : to start the development of a new release.
git flow release finish <name> : to end the development of a new release.
git flow hotfix start <version> : to start the development of a new hotfix.
git flow hotfix finish <name> : to end the development of a new hotfix.
GitFlow will be choosing for you : the starting branches, the target branches, creating tags and deleting the right branches.
Of course, there are a lot of other commands out there, but these are the most important to me.
For the rest, just use your regular Git commands.
Dig deeper
This workflow is pretty. Everyone using it have probably made big progress in their work's quality. But there are a lot of enhancements possible.
For example, unit, end to end and performance test automation, as well as deployment in production automation and/or in integration directly from those previous tests.
EDIT :
After reading this post, some of my colleagues asked me how to execute GitFlow in a more complexe project where developers have to maintain several versions simultaneously. The question being fair, I wrote another post on the topic.
Join 250+ developers and get notified every month about new content on the blog.
No spam ever. Unsubscribe in a single click at any time.
If you have any questions or advices, please create a comment below! I'll be really glad to read you. Also if you like this post, don't forget to share it with your friends. It helps a lot!