It seems that, let’s say we have everything commit as “Version 1.0 done”, and now we want to add a feature, it is good to create a branch, say newfeature, so that when we need a “hot fix” or “quick fix”, we can switch between the master branch and the newfeature branch.
But I do see in an example that, the operation is:
git checkout master
git checkout -b hotfix
// now do any fix that is needed in Emacs
git commit -am "finished hot fix"
git checkout master
git merge hotfix
git branch -d hotfix // delete the hotfix branch
The question is, should hotfix be created and go through all the merge and deletion of hotfix? Why not just switch to the master branch and do the fix and commit it, and that’s it? Is there a good reason to create the hotfix branch?
if you are using the master branch as develop branch its in my opinion usless to make another branch for hotfixes. But if you are using a branching model like this, its very usefull.
They are using seperate develop and master branches. The master branch is only for tagging release versions. So if your customer has a problem and you want to do a hotfix, you can make a hotfix branch from the master release tag. So the hotfix is comletely detached from your normal development branch and the customer only gets what he wants, the hotfix.
Merging and deleting branches is also ok. If you are using –no-ff you can reconstruct, that there was a merge.