Resolve git auto merge from release branch to master conflict

Question

I don't even know how to summarize this issue, so having a hard time searching for similar questions.

My company has our repos setup so that work for our next release is done by creating a branch from the master branch, making changes, then merging that branch back into master. When we do a release, we create a "release-<#.#>" branch from master. Now if something in that release needs to be modified, we create a branch off of the release-<#.#> branch, make changes, then merge back into the release branch.

I should note that no one is allowed to commit anything directly to master or release branches. The only way to update those branches is by working in another branch, creating a pull request from that branch to either master or a release branch, getting that PR approved, then merging it.

We then have an "auto merge" from the release branch into master, to make sure master always gets those changes as well. I'm not sure if this is a good idea or not (it definitely causes headaches for me often), and not interested in debating that, but I need to figure out how to address the following situation.

I have a file, somecode.java. We branched release-2 from master, did the release. I kept working for the next release, and updated somecode.java in the master branch.
Now we discover that there was a problem with release 2, and I had to make a "fixit" branch from release-2 branch. In the fixit branch, I updated somecode.java, then merged it back into the release-2 branch.
Now the auto merge from release-2 to master fails because the version of somecode.java in release-2 conflicts with the version in master.
Is there some way to tell Git to either
(1) keep the version in master (preferred, since the changes in release 2 have been superseded by the changes made earlier, but after the release-2 branch was created, in master) or
(2) overwrite the version in master with the newer version from release-2 (and then I'll just update the master version later with changes already made to it there)?

I know I could just decline the auto merge pull-request from release-2 to master, but then any time someone else tries to update the release-2 branch, they'll get the same merge conflict when their auto merge is attempted.

I tried doing a
git checkout origin/master -- somecode.java
while working in my "fixit" branch, and then updating the file to be how we need it for the release 2 fix.
I thought that would be the equivalent of telling Git "for this file, we're starting with the master version, so when we update it here, it should clearly overwrite the version in master". Basically option (2) above.
But it didn't make any difference, and still had the same conflict when doing the merge from release-2 to master.

Any suggestions?

Answer 1

overwrite the version in master with the newer version from release-2

That's the strategy I would suggest. I don't know anything about automerge — how often does it come back and try to do this again? But if you work on master and checkout the release branch's somecode.java, overwriting master's version, and add-commit-push that to the server, the automerge can subsequently succeed. You can then edit somecode.java again so that it is right (presumably by means of a copy you have retained elsewhere before the checkout).

But as you rightly say, the entire automerge strategy is suspect. It muddies the waters in a way that makes no sense to me. What is the good, I wonder, of trying to read back onto master a hotfix intended purely for a version that has already been released? If something in the hotfix turns out to be useful, it can be cherry-picked by hand on to master; otherwise, it should remain on the separate release branch, as these are clearly intended to be separate histories and separate lines of development.