- What about project managers?
- What about delivery or team leads?
- What about those brave souls that spend hours and hours managing a long train of parallel development, hoping that everyone manages their code well and hoping that the final release is squeaky clean
- What about those nightmares that these souls have every time someone talks about fixing something in the current, perfectly running piece of code?
Well, fret not – we have GitFlow.
How do we do it?
The principle behind GitFlow is to assign the branches some strict roles and manage the code merges and commits according to those branches.
GitFlow suggests that we start our project with two main branches namely,
- Master
-
Dev
-
Feature-xxxx
-
Release-xxxx
-
Hotfix-xxxx
Feature Branches
git checkout -b feature-featureName dev
// Branches out to feature-featureName from the HEAD of dev
git checkout dev //switches to dev branch git merge --no-ff feature-featureName //merges feature branch with commit history intact (thanks to --no-ff) git branch -d feature-featureName //deletes and closes the feature branch
Release Branches
Release branches are essentially the staging area for our ‘Dev’ branches before we merge them into the ‘Master’ branch. This release branch then stays alive till the time we later merge it into master as our release for that particular development sprint comes up.
Since we branched out from the Dev branch for this release branch, it is considered that the code at the time of branching was (supposedly) a release ready code and hence all the changes that we do from then all would be treated as patches and committed on the release branch itself. These patches should later be merged back into the Dev branch to keep the development copy of our code up-to-date.
git checkout -b release-1.0.0 dev
// Branches out to release-1.0.0 from the HEAD of dev
git checkout master //switches to master branch git merge --no-ff release-1.0.0 //merges in the release-ready code from release branches to Master git branch -d release-1.0.0 //deletes and closes the release branch
git checkout dev //switches to dev branch git merge --no-ff release-1.0.0 //merges in the release-ready code from release branches to dev
It is also suggested that we tag our Master branch at this point in the merge history so that we can refer back to it later. (More on Git tagging here)
We can do this by simply doing the following,
git tag -a v1.0 -m "Some feature added. Security threat score 10/100"Hotfix Branches
Hotfix branches are nothing but impromptu improvements that we would do on our release-ready code. Just like release branches, hotfix branches also have the version numbers to help us keep track of them.
One essentially important thing we would need to remember is – once the Hotfix development is finished on that particular branch, we need to merge it back in the Master branch and then merge it back into the Dev branch as well.
Although, here’s a rule of thumb we should follow,
“When a release branch currently exists, the hotfix changes need to be merged into that release branch, instead of Dev”
git checkout -b hotfix-1.0.0 master
git checkout master git merge --no-ff hotfix-1.0.0 //merges into master, next, merge into dev git checkout dev git merge --no-ff hotfix-1.0.0 git branch -d hotfix-1.0.0 //deletes and closes the hotfixbranch
The ‘Here’s why’ Part
More than anything else, if we follow this approach for our projects, by now, we should have a very detailed Git tree, ready at our disposal. This Git tree can clearly tell us the features that we added to the project incrementally, the releases that we produced (and at what point in the timeline we did them), and what were the patches and hotfixes we applied at what point.
More importantly, for developers, it creates several milestones that they can roll-back to if things don’t go as per the plan, and for project managers, it gives a crystal clear visualization of the development as it goes on in parallel and a picture of rapid feature merges as they come in and happen on the fly (without disrupting the development).
