I have the following situation:
Rebasing to get a "clean" history is overrated. The best way if you want to preserve history is just to do the merge instead of a rebase. That way if you ever need to go back to a revision, it is exactly the same as the one you tested during development. That also solves your issue about the previously solved merge conflicts.
If you don't care about preserving history, you can create a new branch off of master, check it out, then do a
git read-tree -u -m dev to update your working tree to match the
dev branch. Then you can commit everything into one big commit and merge it into master as normal.