Git detects files as newer after reverting a merge, so it doesn't show conflict

I have this scenario: There are 2 branches, 'develop' and 'feature-branch'. This two branches have been growing over time each one independently. Now, 16 of November of last year, a merge was done from 'feature-branch' to 'develop'. This merge should not have been done so it was reverted on 19 of November. The problem: now the files in develop are newer, so when doing a merge from 'develop' to the branch to integrate both, git keeps the files in develop. This is a problem because there is code on the branch which is necessary, and since it doesn't create conflicts, I'm not able to integrate them. I would need to manually check every file and check the logic, which is not ideal. Is there any way of fixing this?

1. Checkout a new local branch called 'prepare-develop-for-merge-into-feature-branch' based on the merge-revert commit of 'develop'.
   git checkout -b prepare-develop-for-merge-into-feature-branch <commit-id-of-merge-revert>
2. Create a commit that reverts the merge-revert
   git revert HEAD
3. Checkout 'feature-branch'
   git checkout feature-branch
4. Merge 'prepare-develop-for-merge-into-feature-branch' into it
   git merge prepare-develop-for-merge-into-feature-branch
5. Merge actual 'develop' into 'feature-branch'
   git merge develop

The result should then look like what you'd expect it to look if that merge-revert never happened.

Note: There are other approaches to solving this (e.g. reverting the merge-revert direclty on top of feature-branch). However, I've chosen this approach, because it should cause git blame to still point at the original commits (instead of the revert-revert) while also keeping possible merge-conflicts to a minimum.