How to review hundreds of commits and formalize merge request(s)

Question

At my work every line of code must be reviewed and this review is formalized in a merge request.

Now we are a facing a situation were one developer developed a prototype for a new product which is now going in production. There are a few hundred commits and lots of line changed all in one branch. I'm wondering what would be the best way to both review the code, formalize it with merge request and keep relatively clean history.

I have thought of two ways:

1. The simplest way would be to review all existing code, do a merge request and merge the prototype branch in master (or a development branch). This solution would take time until being fully finished and could be mentally taxing for reviewers but keeps the git history.
2. Another way I thought, would be to review component by component. In a new branch we create a new history were we commit one component each and do multiple merge request. This solution allow us to see progression and formalize that each component is validated (and not just a big chunk of work) but we would write a new git history that could cause merge issue.

Answer 1

Just the normal route. The developer issues a pull request; you know where this pull request should eventually be merged. There may be conflicts, in that case it is up to the developer to fix these conflicts and update the pull request.

Now a difference to normal operations: Since you expect this pull request to take long, you ask your fellow developers not to merge into that branch until the pull request is done, to avoid getting new conflicts that need merging, possible invalidating your review.

Then you review, which will take a while, and merge. Your review can be done any way you like. Such a large change can probably not be reviewed by staring at diffs. One way that works for me: Create two folders, one for the old branch, one for the branch that should be merged in. Totally outside of git control Use a good diff tool to actually move the changes into the old branch. Like "New branch added a file X", so I add an empty file X to the old branch. "File X contains a new function f", so I move that function f to the old branch etc. Obviously you don't do this blindly, when you add the function f, that's where you check it.