Git Ready, Set, Flow - An Intro to Git Flow Practices
Photo by Arisa Chattasa on Unsplash
In this blog, I'm going to cover (what I think) is a lesser known branch type which is part of git best practice: release branches. To do this, I think it's pertinent to talk about repo set up too, so bear with me..
If you're new to git and branches, you can check out my previous posts: What is Git? and Getting Started with Git.
The 'ideal' git repo set up
Okay, so I say ideal in inverted commas because there are some different schools of thought. This is the way I like to have a git repo set up and which is the basis of the approach I'm taking in this blog post.
When I start a new project, my preference is to set up my develop and main branches right away. They are all then empty or at least only have the initial commit/file structure and created, which will make things easier later on.
What are the different branches?
develop - this is your most active branch, you branch of this one when you develop new features and these feature branches get merged to develop through pull requests.
main - this is where your 'final' code sits, this code is considered 'production ready' i.e. it is the code that could be picked up to go into production without any changes. It's been tested and checked. In theory, once you have code in main should need no fixing or changes.
You may be looking at the above, and thinking...okay great I know where my active branch is and where my tested code sits...but how do we get from develop to main?
This is where the release branch comes in...
The Release Branch
When your develop branch has reached a certain milestone, whether that's a certain amount of features or some other defined point, it's time to collect those together. Here we would branch off develop, just as you would for any new feature branch, except you use a different naming strategy. Convention would dictate that you would use release/0.1.0 for example...for version 0.1.0, with numbers increasing to represent your branches. For more details on numbering your releases you can check out this handy guide on semantic versioning (the name of this numbering system).
Once you have this branch created, there should be no additional features added to it. This is the branch that goes into your testing environment. Any bugs found through testing require changes, these would be done by branching off the release branch and making a 'bugfix' branch. This is then merged directly into the release branch.
When you're happy with the release branch, all fixes have been made, you would then raise a PR to merge the release branch into main. This is where it is handy to have a main branch right from the beginning of your repo, as otherwise you have to find a workaround for your first release as there is no main to merge into!
Finish the release process by pulling from main into develop, so that all bugfixes etc. are available now in your develop branch, and therefore incorporated into any new code.
Wait...there's a bug in main...
Argh - you think everything is sorted, your main is being put into production....and then a bug is found. Now what?
Meet the 'hotfix' branch, this is a branch that bypasses most of the normal rules to get something fixed in main ASAP and should be reserved for urgent fixes only. Here, you would branch of main, creating a hotfix branch, fix the error and raise a PR to merge directly back into main. (I hope you're seeing here why we reserve these only for very urgent fixes, as the potential to mess up the production code base is high as some of the safety steps are bypassed!!)
Once the hotfixes have been implemented, to make sure these make it back to the develop branch, and all new code you will need to pull from main directly back to develop.
That's it - well, it's it for a simple overview of one way release branches can be managed in git. There's loads more reading out there on exact hows and documentation you can check out. But hopefully this gives an idea of the reasoning behind these methods.
