We spent a good part of a day rebuilding a repo after a junior dev. left, when we found out they'd misused global gitignore and hadn't commited several important files due to an ignore they had set for a seperate project.
Lessons learnt. Ensure new devs don't use it, and code review on another machine than theirs...
lmao!
Shocking I know /s.
But not everyone on here is part of a 20 man SV tech startup making the next social media for beagles and deploying 50 times a day...
A broken code should not be able to make it to production, there should be several steps to prevent that, including: Peer review, CI, QA, a staging environment, manual testing, etc.
Always assume that developers can screw up in trivial ways, and build your delivery system such that trivial screw ups will be caught early, rather then dictate how your devs setup their work stations.
Also don’t code review the code it self, review the diff.
A significant percentage of the most critical problems I detect during reviews is in the parts that have not been changed, invisible in the diff. A good diff is necessary, but not sufficient.