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

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)