Contribute like a Pro. Git-branching model (Part 2)

Refresh

From Part 1 of this article, we discussed about --no-ff flag when merging. It helps to keep track of log messages of events happened in your sub-branch (feature branch) and you can easily roll back. Now lets look something else...

Releasing process

Like the feature branch, it is a separate branch but created as sub-branch of develop branch. It is a branch which contains all necessary environment, support and features for production of your application. It's the branch you need only during production process. Two main things can be found in this branch:

• Meta-data(version number - tags, build dates)
• Minor bug fixes

Create a release branch

When do you create a release branch? You should only create a release branch when all targeted features are fully developed and merged back to develop branch ready for release. Divide and Conquer mindset is very important when dealing with your software. I advise you to build your software in feature-wise that is, you release one feature after another until the entire software is complete. If you're building alone, you should not start building another feature before releasing a current feature. Divide and Conquer mindset will save your time and energy too.

For example, say version 0.2 is a current production release (in develop branch) and we have a new release coming up called version 0.3. We will branch off from the current state in develop branch and create a new sub-branch of the develop branch called release-0.3. It's name will point to the coming release, shifting from version 0.2 to 0.3, a new release! This is how you'll do:

#Create a release branch
$ git checkout -b release-0.3 develop

#Bump the version from 0.2 to 0.3
$ ./bump-version.sh 0.3

#Make a commit
$ git commit -m "Bump v0.2 to v0.3"

Note that bump-version.sh is just a custom bash script you'll write to change version of your software (you can also use git actions or CI tools)

You can fix some minor bugs in this branch rather than doing it on the develop branch. But it is not advised to add large new features here.

Release a release branch

Now the software is ready for production. Our sweet feature in a release branch should be merged into the master. Remember in Part 1, master branch will always contain "clean codes" with no bugs at this point in time. After merging our branch, we should tag it, just to mark the branch with a summary of what we've done for the future reference. And finally, updating the develop branch. In summary:

• Merge the release branch into master branch.
• Tagging the branch for future reference.
• Update develop branch with clean codes so that the future development also contain the bug fixes.

#Into master branch
$ git checkout master

#Merge the release into master 
$ git merge --no-ff release-0.3

#Tag it
$ git tag -a 0.3

#Into develop branch
$ git checkout develop

$ git merge --no-ff release-0.3

What about hotfix branch?

As the name suggests, this is the branch which you'll create for the purpose of fixing bugs that maybe found (or arise) in a master branch. But we said, master branch must contain "clean codes" right? So why bugs in a master branch? Well, the answer is - software becomes real when reach to a user. That's when you realize the bugs - Uncaught fish :) Here's the snippet:

#Create a hotfix branch 
$ git checkout -b hotfix-0.3 master

#Fix the bugs and commit
$ ./hotfix-version.sh 0.3
$ git commit -m "Fixed bugs in production"

#Update the master branch
$ git checkout master
$ git merge --no-ff hotfix-0.3

You can also update the develop branch with this fix just to contain the same clean codebase. After the fix, it's your choice to delete the branch or leave it for your reference. Up to this point, your codebase should be stunning with zero conflict !

Congratulations, you're Git ninja now!

Written from here