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?
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...
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 :
develop. It is strictly forbidden for devs to write on those two branches.
master branch is the mirror of our production. Thus, we can not push modifications on here directly.
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 :
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
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
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 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
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 ones are the most important to me.
For the rest, just use your regular Git commands.
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.
After reading this post, some of my colleagues asked me to execute GitFlow in a more complexe project where developers have to maintain several versions simultaneously. The question being fair, I wrote an other post on the topic.
Many times as a mobile developer I have to work on apps without the API ready that was crucial for the feature I was implementing. Either the backend was developed by another team that was not entirely in sync with us or our backend team had no chance to implement those endpoints earlier. For this reason, I was not able to satisfy the Definition of Done but it does not mean that I have implemented the UI only.