DEV Community

Discussion on: Git branching done right with Gitflow & improving code quality with code reviews

Collapse
 
joshcheek profile image
Josh Cheek

Of course, this can work well if you know a person that's going to be committing to your repo. However, it's still not a good solution if you ask me because I doubt it that you'd like your junior developers to commit to master without you at least checking the code.

I prefer to trust people to introduce these things as they think it's valuable. If they're not sure it should go in, then they can send a PR. If they think there is risk to their code, they can request a code review. I don't see value in mandating these things, it implies distrust and adds frequently pointless overhead, I'd expect the natural reaction to be taking less time during a code review, undermining their effectiveness.

Collapse
 
nikola profile image
Nikola Brežnjak

Our team's policy is that no code is commited to master before it passes a code review.

A code review is not there to convey distrust but it's there to strengthen the codebase and keep the reviewer up to date with the changes. Sometimes you don't notice what someone else will, by looking at your code.

After we got used to this, everybody across multiple teams agrees this was (for us) a great thing to do.