Why You Should Adapt Gitflow
GitFlow is a convention that says how you should structure your development process. It tells you when you should branch and merge your changes and helps you with hotfixes. By organizing branches effectively it unblocks developers allowing them to stay effective
Key characteristics
Work happens in parallel
Each developer is free to work on his individual features, all is required to branch off develop branch and once the feature is done create a PR back to develop
At later point in time current state of develop is picked up and new release is created.
Focus on releases
GitFlow focuses around releases (see comparison to GitHub Flow below), this means that it’s best suited when you release your code often, but at the same time not too often.
There is some (small) overhead related to organizing a release, so in most cases you would be releasing at most once per day (just a rule of thumb)
Clear separation of ongoing work vs hotfixes
Hotfixes that affect live application don’t interfere with ongoing work.
Most teams struggle with this in simpler workflows (or when there’s no workflow), especially when each PR after review is merged back to master and release of the master happens after a while.
In case of emergency they need to figure out what exactly version is running live, and branch off at that specific moment in the master branch, this is messy and always ad-hoc.
GitFlow deals with this cleanly because there’s one more level of separation between ongoing work, staging area (release branches) and production branch (master)
No more ad-hoc decisions
GitFlow is simple but at the same time quite comprehensive model/convention to how you and your team should structure your development process.
It can be compared to the application framework which tells you in which folders you should place specific files, GitFlow tells you when you should branch and merge.
Reading material
There’s already a good amount of reading material about it, so I’m not going to repeat those resources:
- https://datasift.github.io/gitflow/IntroducingGitFlow.html - good and short introduction to GitFlow
- http://nvie.com/posts/a-successful-git-branching-model/ - article that introduced GitFlow to the public
- https://githubflow.github.io/ - simplified version of the model: GitHub Flow
- https://www.atlassian.com/git/tutorials/comparing-workflows - a comparison of few Git workflows
Note about GitHub Flow
GitHub flow in general is very similar to what most people do out of the box with git, but with one exception. GitHub Flow requires you to deploy master to production after each merge. In my experience most teams are not ready to adapt it, or feel uneasy about it, therefore GitFlow might be a better convention for them.
Tooling
There is a whole tool dedicated to GitFlow https://github.com/nvie/gitflow which might be useful for some people. In my experience I’m happy with just using hub to help with creation of branches and PRs: https://github.com/github/hub
Summary
I think that once a development team reaches certain size you should introduce a workflow to organize your development.
GitFlow seems like a good choice, it’s well documented, widely used, easy to understand.
It brings along a small overhead but there’s always a price to pay for having a structure. I think it’s definitively worth to have some structure versus ad-hoc decisions, especially made at stressful moments, like hotfixes on production.
