How should gitflow hotfixes work?

Question

We use Gitflow for our web builds, and I have a question about how hotfixes are supposed to work. But first I should explain that we don\'t quite use the n

Answer 1

For first picture in this link

I don't see why there would be many conflicts. The changes which are merged to develop are only the latest hotfix, of maybe previous hotfixes, if they were not merged for some reason in their turn.

(though I would rather merge the hotfix into master, and them merged master to develop, instead of directly merging hotfix to develop, just to avoid criss-cross merges, but it should not change much)

Answer 2

I believe you will see the same conflicts if you merge your master into develop, even without a hotfix.

So the hotfix itself isn't the problem. The real question is, why does merging your master into develop generate so many conflicts? The answer is that gitflow was not followed correctly, otherwise every commit in master would have been merged into develop already. When done right, the hotfix merge works the way you expect: only the change in the hotfix should be new.

The following should fix it. Do a fresh merge of master to develop without immediately committing. You will see the conflicts. Resolve them all in favor of the develop branch (e.g. reset and remove all changes.) Then commit the merge. This "empty merge" should tell git that develop has everything that's in master. Future hotfixes should then work better.

I ran into this same issue recently. I don't know how our history got confused (or yours). Maybe a developer committed a change directly into master and never merged it back. Or maybe they had problems and tried using separate commits instead of merging a change from one to the other. It's likely to happen again so maybe next time I'll figure out who or what is the culprit.