CMIIW, the famous git-flow workflow above suggests the step for conducting a hotfix is as followed: stable branch: 'master' working branch: 'develop'
- branch 'hotfix' out from 'master'
- fix and commit to 'hotfix'
- merge 'hotfix' into 'master'
- merge 'hotfix' into 'develop'
- del 'hotfix'
My question is why do we need to create a 'hotfix' branch? What would be the [harm/drawback/lack of flexibilities] if we do this
- checkout 'master'
- fix and commit to 'master' and call the commit like "DEBUG: some fix"
- merge 'master' into 'develop'
My guessing is that 'hotfix' branch is trying to follow the same paradigm as 'feature branch', where we don't directly commit to 'develop' and 'master'. But the 'hotfix' branch generally requires only little code changes in my case (eg. getting rid of an extra comma that causing SQL error), which I personally don't find it worse the effort of creating a new branch.
If both ways are fine, how do I judge when to use what? Based on the amount of fixes?
If my proposed way is not good, could you specify what issues it could potentially cause or what flexibilities it doesn't provide compared to the standard way?