If you think the code should be fixed before merging, make comments. Preferably with "why" so the dev can learn.
Keep in mind code is read far more often than written. So things which seem "minor" can actually be really important (variable names for example).
However, if you find yourself making comments which seem tedious, perhaps consider:
- Should your CI process catch these?
- Do you have a clear "developer guide" to reference (or is everything documented in your head)?
- Do these comments actually contribute to code quality?
A lot of people sacrifice productivity at the altar of process or perfection. Be careful you don't do this.
Try to visit your colleague in person if possible. Or use video calls. Building a relationship makes criticism (even code reviews) easier to manage.
If you find that a piece of code has too many back/forth on issues, request the review over smaller pieces of code. Incremental changes are more likely to avoid some of the more significant design problems, because they are by definition smaller.
But absolutely do not merge stuff and then go back and fix it. This is passive aggressive and if the developer finds you doing this, you will kill their morale.