The first, and second, reason for code reviews is QA (hence points in checklists). Some of it can be automated but overall it makes sense to have at least another human being check that a code change is sensible before it is merged.
Another aspect is that this allows to enforce approval of code changes at project level: ideally every change should have a reason and that should have been approved beforehand (e.g. when you planned your sprint if you're Agile).
This is why the usual process is that code reviews gate merging into the master repo. Ie., pre-merge reviews make sense, post-merge reviews don't.
Another aspect is that this allows to enforce approval of code changes at project level: ideally every change should have a reason and that should have been approved beforehand (e.g. when you planned your sprint if you're Agile).
This is why the usual process is that code reviews gate merging into the master repo. Ie., pre-merge reviews make sense, post-merge reviews don't.