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 normal Gitflow workflow.

I understand that usually you would branch your features, they would merge into develop when finished, you would create your release, release gets merged into master and you deploy that, as an actual "versioned release".

However, as this is client work, we don't do "releases", instead features are deployed as and when they are required, so changes from our feature branches are merged into master on an ad-hoc basis.

This did cause problems as the feature branches were branched from develop which was way ahead of master; merging these feature branches into master would merge other changes into master (changes that were present in develop at the time the feature was branched that weren't yet in master). We were aware that this is not how Gitflow is designed, but we needed a branching model of some sort, so we (sort of) solved this by cherrypicking commits instead of merging branches.

So, I understand these issues, and I don't believe they're contributing to the issue I have now, but just in case, this is how we use it. However my question is:

How are hotfixes supposed to merge in?

In my head, the scenario is:

• master is "production"
• develop is ahead of master

You then want to patch an immediate issue with a hotfix branch. In Gitflow, this branches from master, and when you finish the hotfix, this gets merged into master and develop

But how does this not cause massive problems?

Recently, I tried to create a hotfix to change a single line of copy in one file. I finished the hotfix, and the change merged into master with no problems, but when it tired to merge into develop, it created an enormous 35 file diff with several merge conflicts in files I hadn't touched, due to the disparity between develop and master.

I understand that this is because you are merging the hotfix branch, which was itself branched from master, into develop, not specifically the change or single commit, so I understand why there was the massive merge commit/conflict.

However, what I don't understand is, with this in mind, how hotfixes work at all "in the real world", considering they are branched from master and then merged into develop, which is, by design, way ahead of master. This is why I don't think the way we're using Gitflow is the issue, because develop would be ahead of master regardless of our non-standard deployment process - I can't see why this doesn't cause huge headaches regardless of the project or exact workflow.

What doesn't seem to make sense to me is that your hotfix could be something as simple as changing a true to a false or changing an email address, whatever, but to get it into master, you may have to wrestle with an enormous set of merge conflicts. Is this just standard behaviour? Is this just how hotfixes work, and if you have to sit and sort out a massive merge conflict, then so be it? Would it not be easier to just cheerypick a commit? It just seems like there is such massive scope to introduce an error for what could be such a tiny change - you're dealing with two branches that are, perhaps, several months and hundreds of commits away from each other.

I may just be misunderstanding the process of hotfixes, but if I am, I'm not sure which bit.

Answer 1

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.