git flow is among one of my favorite ways to teach git, and frankly one of my favorite ways to use git. It’s a pattern to follow and one of the best parts about git flow is that it makes automation on top of git very simple. Additionally, most of the graphical user interfaces already have it built in, so you can’t lose.
What is it really?
git flow is nothing except a git branching model. If you already read git branches simply explained and git Merges Demystified in our git series, then you have all the tools needed to start using git flow. Initially published by Vincent Driessen, the git flow model has been a welcomed pattern for git branching and from there the tie ins to it have been just flowing.
In the diagram below, you can see the basic pattern of git flow, but while it looks like a bad subway map, it really is an easy pattern to follow. Essentially, it gives you a few different things that don’t come out of the box with git. There’s a way to fix production code, work on new things, and even prepare for deployments. We’ll cover all of them in detail in the next few sections.
This is production code - simple as that. The big change that git flow adds to the mix is that you don’t actually code ever on master. Everything here is done via merging or pull requests. This ensures that your code has gone through the process and is ready to go!
Need to fix production? Easy, start a hotfix branch and code away. When you’re done something different happens, a double merge - one into master and one into develop, ensuring that the bug you just squashed does not come back!
This branch-like master is not committed on directly, it is a direct copy of the master branch when you enable it though. This is a one time thing, so keeping the pattern will ensure that the branches stay synced together. Merges will happen to it from both hotfix and feature branches - develop acts as an integration branch to that extent. The beauty of this is that all of the code comes together before a deployment, saving you time and lots of unneeded stress.
This is the closest to normal git branching as you will get in git flow. Essentially, it’s a place to try out and implement new functionality. This is great, because you can have virtually unlimited features in progress and never have to worry about them breaking the main branches. On that note, you really want to start and end a feature as quickly as possible to avoid merge conflicts, because no one like them.
This is one of the greatest built-in features of the git flow pattern. This gives you a place to start staging your release to production. While that is awesome on its own, it like hotfix has a double merge at the end of it. This means that if a bug or other issue is found during a release you can still fix it and have that code automatically flow into both your master and develop branches.
While git flow will not solve all of the problems that you face in a day, it can help you with a simple pattern for branching. There are a lot of add-on’s out there, which make use of it, and now you can as well. Don’t worry too much though if you cannot use a built in git flow tool either. I personally use the pattern on my Thinkpad Chromebook through the Termux application and have no issues.
Keep in mind there are other patterns out there. Some even include the very popular forking workflow. You should at least explore them so you know your options, but git flow is a solid option if your looking for a little structure in your branching pattern.
Now that we know about git flow, there are a few new things that we can start to look at using the branch naming pattern. Particularly, git hooks which will allow us to do almost anything connected to commits and merges that can be done via a shell script. This is a very powerful addition to your tool box, and might even let you stick your toes in the water for continuous deployment.
If you missed one of the git articles, please check it out from the below series links.