2

gitflow

CMIIW, the famous git-flow workflow above suggests the step for conducting a hotfix is as followed: stable branch: 'master' working branch: 'develop'

  1. branch 'hotfix' out from 'master'
  2. fix and commit to 'hotfix'
  3. merge 'hotfix' into 'master'
  4. merge 'hotfix' into 'develop'
  5. 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

  1. checkout 'master'
  2. fix and commit to 'master' and call the commit like "DEBUG: some fix"
  3. 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?

Mafick
  • 1,054
  • 1
  • 12
  • 25
alson_y
  • 33
  • 5

1 Answers1

2

master/ (or now main) is supposed to reflect what is running in production at any time.

And when you are doing commits on an hotfix branch, you need to test/validate those commits do fix the bug.
Only once the validation steps have been done can you merge to master/main.
And possible to develop (although you can have a bug in production which is no longer relevant in develop, because of new features which render said bug moot)

The goal is also to avoid any merge from master/main. You merge to it, not from it, in order to keep any possible merge conflict limited.
Plus, merge are done with --no-ff (no fast-forward), as discussed in petervanderdoes/gitflow-avh issue 257: the goal is to clearly see from which hotfix branch the development commit created by the merge comes from (instead of just coming from "master/main").
Again, not all bugfix publish to master applies completely to develop anyway.

VonC
  • 1,042,979
  • 435
  • 3,649
  • 4,283
  • Thanks for the answer. The test/validate part is a pretty good argument to use hotfix branch. Could you elaborate a bit more on your last point on "avoid merge from master/main to avoid merge conflict"? From my understanding, if you merge hotfix branch into master/main, then they would both point to the same commit. Then merge hotfix or master/main into develop would be the same? – alson_y Aug 03 '20 at 06:03
  • @alson_y I have edited the answer to address your comment – VonC Aug 03 '20 at 06:11
  • Thanks for the update. But to the same line that I was referring to, I still dont get in what situation could merge from master/main results in merge conflict but would not from hotfix, because I thought hotfix and master/main would be the same after merging hotfix into master. Could you give an example of how merging from hotfix as opposed to master/main could avoid a conflict? – alson_y Aug 05 '20 at 01:38
  • @alson_y "conflict" means concurrent changes on the same file. When you merge from master, while development has gone on, you will have conflict (if changes introduced by the hotfix are on the same file as subsequent development). – VonC Aug 05 '20 at 06:03
  • @alson_y I mentioned the concurrent aspect in conflicts back in 2009: https://stackoverflow.com/a/457988/6309 – VonC Aug 05 '20 at 06:09