The main argument against not having a separate commit is that with large projects the history becomes useless when every commit is type fixing. In the case of

The main argument against not having a separate commit is that with large projects the history becomes useless when every commit is type fixing. In the case of fixing typos or making tiny changes that don't really deserve their own commit, the person making the tiny changes should also be the person who made the last big changes too. --- > Why is it necessary to do a code review before a merge, instead of after? Because most of the time you want master to be working, and working as well as possible. In a team environment, you shouldn't all just be throwing everything on master, that leads to unnecessarily crazy history. You review it before to say "alright, this is good, we all like this, this could be placed in production now if we wanted".