How this is a best practice?
What about CI/CD... Every commit to production..?

Wdyt?

Pull requests is what they want you to use. But what does it have to do with CI/CD?

Latencies will be increased. Number of PRs that lies in backlog.

When bunch of guys working on codebase simultaneously and modifying the common parts of the code, it's gonna be real hell with PRs

Getting feedback is slower, true.

Pull. requests?

I do this for robotics codebases. That way, only very trustworthy people can push to master (and the robot during competitions). Everyone else has to do a PR and get approval from a codeowner.

Well I agree with the above if and only if the it is an open source project. In an org, its kinda code smell.

@ewpratten lol, I refused to let anyone else upload code to the robot, and then wrote an enormous sdk for our team so they interfaced directly through my "childproof" layers.

We had GitHub but as we got closer to comepti5ion it was more crunch time, so messenger and zip files to share! During comeptition I once copied-by-hand 50 lines because it was going to be faster than going outside, setting up a hotspot, connecting both computers to that hotspot, doing a push and pull, and then going back inside. FIRST has ridiculous rules -- you'd think by now they would have realized it's important to make reliable hardware, especially for comms that apparently goes down if my phone hotspot is on nearby.

How this is not a best practice? You just don’t allow anyone to:
git push origin HEAD:master
Things like code review, tests, etc are the best practices.

@woodworks we run private ftp servers and stuff like that during comps.

@ewpratten did they change the rules? It used to be if you even had a hotspot going, an FTA would show up with a radar and hunt you down 😫

@woodworks it's wired.