I was recently introduced to a Git methodology called Git Flow. Git Flow itself is more of a guideline that they are rules. Vincent Driessen coined the term, however much like myself, developers were probably already implementing this approach long before it gained popularity, or some variant of it. I do remember working on a small team in a past life, long ago when I was a young and chipper programmer. I do remember collaborating with my dev team and using a flavor of GitFlow. Looking back, I now see it’s power in both and even really large development teams.
I must admit though, s’been a long time since I’ve worked on a team, so this will be an interesting run for me.
GitFlow
This is a good name so kudos to Vincent for giving it the name that it deserves, nothing like implementing a good flow. There isn’t much code talk in this post, instead I’m going to cover five simple things to remember with GitFlow and use the handy dandy GitFlow Diagram that’s gained popularity as of recent.
Five things to remember
Master Branch
Development Branch
Release Branch
Feature Branch
Hotfix Branch
And that diagram…
The Master Branch
I like this approach, it simplifies everything and it really steers clear of any fluff. We basically have a master branch which contains all of the final code that is up to date. This code is what is currently in production.
The Development Branch
The “Development Branch” is what I call “Spawn” (like the comic book character), that’s my my internal naming convention for it. Simply because this is where developers feed from, the “Development Branch” is the code that is currently in development. There can be bugs here, some broken code and a bunch of other things that aren’t found on the master branch.
The Release Branch
The “Release Branch” is what I like to call the “QA” branch. This branch is where code is reviewed before it gets to the master branch. The “Release Branch” is associated with a “Staging Server”.
Feature and Hot Fix Branches
The last two are a bit like micro economics. We get a little more personal especially when creating feature branches. Feature Branches is where all the coding activity takes place, this is where programmers like me spend most of their time, inside the feature branch. This is where a product managers says something like “lets build xyz”, then this feature can be broken down into multiple feature branches depending on how large it is.
Finally we get to the hot fix branch – this hot headed branch as the name suggests, doesn’t even make its way down the other branches. Instead it is taken, the exchange only occurs directly between the master and a hotfix branch. A hotfix branch is a place where a bug, enhancement or some action is implemented and rolled out quickly, maybe even within at least an hours time.
There are videos and articles sprinkled around the interwebs describing this flow in detail but it really doesn’t get any more detailed than this I think. If you’re already familiar with Git, then this provides some structure in which to operate.
