The right way is a little relative, but I’ll show you how it’s been working with our team, maybe I can give you an idea.
The branches of Hotfix are very similar to branches releases (branches that add a new functionality), as they also prepare a new version to be sent to production, but it is not planned. Their idea is to supply the need to act immediately after some problem in the version that is in production. When a critical error occurs it must be solved immediately, so a branch of Hotfix from the master.
The great thing about this branch is that team members can continue the development of the develop (or the name of the main development branch you use, I’ll use develop here to get more didactic) usually while another developer quickly performs a fix for a problem crítico
.
Creating a branch of Hotfix
The branchs of Hotfix are created from the master. For example, let’s say version 1.2 is the version that is in production and due to a serious error, is causing problems. Changes made to the branch develop are still unstable, not eligible for a release for producing. We should then create a branch Hotfix to fix the problem.
$ git checkout -b hotfix-1.2.1 master
# Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
# Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
# [hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
# 1 files changed, 1 insertions(+), 1 deletions(-)
Don’t forget to change the version number after you create the branch. Then send the changes in one or more commits. (If you use this versioning scheme)
$ git commit -m "Fixed severe production problem"
# [hotfix-1.2.1 abbe5d6] Fixed severe production problem
# 5 files changed, 32 insertions(+), 17 deletions(-)
Finishing a branch of Hotfix
When finalized, a Hotfix needs to be merged back into the branches master and develop and now apply the changes back to your branch master.
$ git checkout master
# Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
# Merge made by recursive.
# (Summary of changes)
$ git tag -a 1.2.1
Now, include bugfix in develop as well:
$ git checkout develop
# Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
# Merge made by recursive.
# (Summary of changes)
The only exception to the rule here is when there is a branch release current, then Hotfix will be merged with that branch and consequently merged into develop when the release is finished. Case develop urgently need that bugfix and can not wait, you can merge the branch release in the branch develop harmless .
And finally the Hotfix can be removed:
$ git branch -d hotfix-1.2.1
# Deleted branch hotfix-1.2.1 (was abbe5d6).
You can find the whole process here in this article in English
In this case, your changes will not be mirrored in branch
master
and, if the Issue occurs in themaster
, would not, in fact, be solved. That’s just what you want?– Woss
This, in this example is not being sent to the master branch, the question is whether the order is correct.
– Mike Otharan