We use Gitflow for our web builds, and I have a question about how hotfixes should work. But first, I must explain that we are not quite using the usual Gitflow workflow.
I understand that, as a rule, you will fork out your features , they will be merged into develop , when you are done, you will create your release , release , which will be merged into master , and you will deploy it as an actual "version with version".
However, since this is work with the client, we do not make "releases", and functions are deployed as needed, so changes from our feature branches are combined into a master on an ad-hoc basis.
This caused problems because feature branches were branched from develop , which was ahead of master ; merging these feature branches into master would merge the other changes to master (the changes that were present in develop during the fork of feature that were not already in master ). We knew that this was not how Gitflow was developed, but we needed some kind of branching model, so we (kind of) solved it with cherrypicking, instead of combining the branches.
So, I understand these problems, and I do not believe that they contribute to the problem that I have now, but just in case, this is how we use it. However my question is:
How are hotfixes merge?
In my head the script:
master is "production"develop ahead of master
Then you want to fix the immediate problem with the hotfix branch. In Gitflow, it is separated from master , and when you finish hotfix , it combines into master and develop
But how does this not cause serious problems?
I recently tried to create hotfix to change one line of copy in a single file. I ended up hotfix and the merge changed to master without changes, but when it got tired of merging into develop , it created a huge 32-bit file with several merge conflicts in the files that I did not touch, due to a mismatch between develop and master .
I understand that this is due to the fact that you merge the hotfix branch, which itself was forked from master , to develop , and not just to change or single commit, so I understand why there was a massive merge / conflict.
However, I don’t understand, bearing in mind how hotfixes works in general "in the real world", given that they are branched from master and then merged into develop , which, by design, is ahead of master . That's why I don’t think that the problem with Gitflow is the problem, because develop will be ahead of master regardless of our non-standard deployment process — I don’t understand why it does not cause huge headaches, regardless of the project or the exact workflow.
It seems to me that your hotfix may be something as simple as changing true to false or changing your email address, whatever it is, but for it to get into master , you may have to deal with a huge number of merge conflicts . Is this standard behavior? This is exactly how hotfixes works, and if you need to sit around and deal with a massive merge conflict, yes? Wouldn't it be easier to just pick up the commit? It just seems that there is such a huge amount to introduce an error for what could be such a tiny change - you are dealing with two branches, which may be several months and hundreds of commits from each other.
Maybe I just misunderstand the hotfixes process, but if so, I'm not sure which bit.