CODEWITHSUNDEEP
gitgit-flow
S.Richmond
S.Richmond

Reputation: 11558

When using Git Flow to manage releases Vs develop, how do you apply a hotfix retroactively?

We're currently using Git Flow to deal with applying hotfixes to our released version of our software as well as the internal develop version. The process works pretty well - A coder decides ahead of time if the issue needs to be in the live version ASAP and will create a hotfix branch before committing their code that will be merged into develop and master.

However, on occasion a commit with a fix to some issue turns out to be a big issue and one we want on the live master branch. How do we do this properly right now?

At the moment we're cherrypicking the relevant commit/s into a dangling branch from master that we're maintaining, with the view that once it calms down we'll do a minor patch and bring master up to date with develop.

My understanding is the cherrypicking commits on to branches like master will eventually cause some painful merge conflicts later on when one tries to merge in develop for a feature release, no?

Upvotes: 1

Views: 688

Answers (2)

Vy Do
Vy Do

Reputation: 52516

However, on occasion a commit with a fix to some issue turns out to be a big issue and one we want on the live master branch. How do we do this properly right now?

--> For any reason, never commit directly to master branch, even when development team in urgent.

Best practices to follow

Need only few seconds to fork a new (hot-fix) branch, need only few seconds to merge hot-fix branch back to master branch. You need revise, commit, commit again, unit testing, integration testing, etc. before merge back to master branch.

See enter image description here

Source: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

And see a well-know post: http://nvie.com/posts/a-successful-git-branching-model/

Upvotes: 1

max630
max630

Reputation: 9238

will eventually cause some painful merge conflicts later on when one tries to merge in develop for a feature release, no?

Correct. It might be not the case, if the change is exactly the same, then there would be no conflict. But quite often there are, and a bad kind of one - which has same change on both sides.

It was repeatedly said about gitflow, that master itself should be merged to develop as soon an there is anything new. It would help in this case as well. Or you can just merge the cherry-picked hotfix immediately into develop, just to not postpone the conflict resolution.

If the conflicts are still hard to resolve you could revert the hotfix first in master. Just make sure you it was really picked to master

Upvotes: 1

Related Questions