Branching strategy and some context:
My team has a few sub-teams, each working on a separate project with its dedicated branch. The master branch has the common functionality and houses a major software component (let's call it system P) used by all the projects. We upgrade system P in the master branch every month or so, and projects merge the master branch into each project branch when necessary. As of today, the master branch is on version 99 of system P.
My project branch (let's call it the M branch) has a long divergence from the master. In fact, master has never been merged into the M branch since we created M 5 months ago.
My mission is to update M to 99.
The approach:
I decided to merge incrementally, one by one, starting from 97, resolve conflicts, build, and move on to the next version.
The problem:
While trying to merge 97, I got an "Already up to date." Upon digging, I discovered that a colleague had inadvertently merged master to his feature branch 3 months ago, which would be merged to M. The bizarre part (and I'm not sure how this happened) is that, even though it's merged, the content of 97 did never show up in the final PR and was never added to either his feature branch or M (and he doesn't remember what happened. I looked in the history, there was never a revert commit). So I'm in a situation where, as far as git is concerned, 97 is merged with M, but the actual content of M is missing.
The question:
So, how do I merge 97 into M without changing the history when git won't merge? Should I try to remove the faulty merge commit from M and then try to merge master with M?
My sub-team is open to working with me if changing the history is the last resort, but what steps do they need to take in case we have to rebase? Will they be affected if they don't have any local branches?
Make a new branch, cherry pick 97 into it, resolve merge conflicts, and merge the new branch.