0

Scenario - using git-flow or similar:

While underway with a stream of work, we become aware that one of the features which has been developed (in a feature-branch and already merged to the develop branch) needs to be urgently hotfixed before the other work in develop will be ready.

What is best practice for achieving this?

In git-flow, hotfixes are typically done using a hotfix branch off master. To follow that model, I'm wondering whether cherry-picking from develop to the hotfix branch is best, or retaining the feature branches after they've been merged to develop and merging those branches to the hotfix branch (or master)? Or something else?

Peter Howe
  • 1,403
  • 2
  • 16
  • 30
  • not sure I understand the question, what is the problem with writing a patch to fix the issue? – OznOg Oct 03 '18 at 18:54
  • In git-flow, hotfixes are typically done using a hotfix branch off master. To follow that model, I'm wondering whether cherry-picking from develop to the hotfix branch is best, or retaining the feature branches after they've been merged to develop and merging those branches to the hotfix branch (or master)? – Peter Howe Oct 03 '18 at 18:58
  • A feature branch that has been merged only into develop, i.e. a release which includes this feature hasn't been made, is considered to still be in active development. As a result, the concept of a hotfix branch doesn't/shouldn't apply. Instead, I would just create another "feature" branch from develop, correct and verify the problem, then merge it into develop. No need to involve the master branch, or create a hotfix branch. – Gary Ewan Park Oct 03 '18 at 19:05
  • But this fix is urgent and needs to be released before other changes in develop. – Peter Howe Oct 03 '18 at 19:07

1 Answers1

0

First, I'd like to stress that "the good workflow" does not exists in general, "the good workflow" is the one you feel convenient to work with.

That said, I personnally consider two situations:

  • the hotfix is trivial (like replacing "Version A" by "Version B" in code), then I would not create a dedicated branch for that (or at least, I would use a fast forward for merge)
  • the hotfix needs quite a lot of work, and then creating a branch to hold those devs is a good way to ease review and identifying all work that was pulled by this bug fix. This could help performing non regression tests later.

If you are owner of your git repo, you may also "rewrite history" by suppressing the merge of the "almost good" feature, and fix the feature to re-merge it later on. This is usually not praised as "changing the history" but if you are just a few developper on the code and everybody is fine with it, that is a possibility.

OznOg
  • 4,440
  • 2
  • 26
  • 35