Some companies like Quora review the code after code is commited and pushed to production. Do you think it's a good strategy? What do you follow in your teams?
Well there is no simple answer. Heavily depends on your team. And on your overall workflow. The benefit of post-commit is, that you can take some time to deeply review and comment it. On pre-commit you're always in a hurry, because features / fixes need to be delivered.
If you have a solid workflow, with testing / ci . I think it's okay to make it post-commit. However you can also automate it if you make it pre-commit.
My preference would be for a) pass tests locally b) send a PR to a branch (the two can be flipped if the tests are run based on PRs) then c) initial light code review/revisions then d) merge to development/beta/testing/staging branch e) bleeding edge people can try it out and offer more code review then e) push to production.
Step d) should pretty much happen as long as the code is not nefarious and fixes more than it is known to break and does not make a huge mess -- not all contributers to a project will have the patience to get code "perfect" so the standard should be "good enough." Even such people are more likely to return with refinements if they see their work accepted, but if they don't, if their patch is an improvement even if not thorough, the users win, and other developers will have less to fix.
But, all this requires a certain minimum number of active developers.
Denny Trebbin
Lead Fullstack Developer. Experimenting with bleeding-edge tech. Irregularly DJ. Hobby drone pilot. Amateur photographer.
Post-Commit. Our master branch contains only the code which we deploy into production. The repository owner has the last word about which code makes it into the master branch. Commit, Review, Comment, Pull, Repeat.
We are not allowing any hotfix to sneak or passing by and violet rules or shortcutting the processes.
In our manufacturing and production area, we have 27k employees relying on our software quality. In case of fire, we can't allow our firefighters to flood the whole production if only a small room is burning. That's why no hotfix can be so important to get pushed directly into master. Instead, we are activating all team members to be ready at times when code is written, committed, reviewed, and pulled into the master branch to reduce waiting times between each step. Also, we change priorities of hot-fixing tasks to be the only activity for each team member until the committed, reviewed, commented code is pulled into the master branch.