Gitflow, as originally written by Vincent Driessen, has become one of the most used version control work models. Using gitflow allows to apply a pattern of best practices when developing software… Which actually it’s something that any other workflow model does. The main advantage that gitflow offers over its competitors is that it makes daily work easy. Naming conventions are clear, and a glance to your latest pushes gives you a clear overview on who works on what, and what’s the status of a release.
Reduced to its essentials, gitflow uses two branches: develop and master. The first one is used to prepare your next release, while the second one holds your deployments to production. The premise is that all code pushed to master is as stable as it can be. New branches are created and then merged back to any of these two branches. Features grow from develop, while hotfixes are created from your master branch. Finally, your release candidate is created from develop, and it’s your transition from “new iteration” to “current version”.
Most branching models advocate to hold a single main branch, and then tag specific changes to mark “releases”. While it’s true that gitflow adds a layer of technical complexity, I believe that improves the readability of a project, as it offers a different perception. Think of develop as a waiting room, a different space from master, inside which you store changes that will eventually get released. Hotfixing issues in the already released code gives you isolation against the current sprint, which is something critical in any fast-paced environment.
Git allows for very comfortable collaboration between developers. Changes can be shared without using a centralized repository, giving room to tinker with proof-of-concepts or making different approaches for a single feature. If something needs to be scrapped, it can be done without cluttering the main lines logs: it’s as simple as not merging back the changes to the parent branch.
An unexpected increased value that comes from using this model is how seamlessly fuses with CI/CD approaches. Watching for pushes on certain branches simplifies when code changes are meant to be deployed on integration, pre-production, and production environments. Artifact generation for Continuous Deployment can be built up with new features until tagged fit for release.
Gitflow can be easily adjusted to big teams as much as you can adapt it to small ones. It’s intuitive, has a small learning curve, and allows for harmless adoption without altering heavily your workspaces. It is my believe that any semantic-versioned project can benefit from these guidelines, and I would like to encourage you to try it for yourselves.
Also published on Medium.