I’m a senior at a large tech company - I push all the teams I work with to automate the review process as much as possible. At minimum, teams must have a CI hook on their pull request process that runs a remote dryrun build of the changed packages. The dryrun makes sure the packages compile, pass unit tests and meet linter rules. A failed build blocks the pull request from being merged.

I try to encourage developers to turn the outcome of every code style discussion into a lint rule that fails the dryrun build when its violated. It saves time by automating something devs were doing manually anyway (reading every line of code to look for their code style pet peeves) and it also makes the dialogue healthier - devs can talk about the team standards and whether the code meets them, instead of making subjective comments about one another’s code style.

Small startup - Here is our process

• Create your branch
• Implement feature
• Test independently of other components (with unit tests or otherwise)
• Test directly with other componenets
• Work with other devs to ensure stability on dev branch, make any small bug fixes directly in dev branch
• Push to prod

Current place:

• Work is done on a feature branch on a personal fork of the repo
• Codebase requires 100% functional coverage, and you’re responsible for writing the tests for your code and including that in the same PR
• Run pre-commit hooks for style auto-formatters before you can commit and push your code to your origin fork
• Ideally run local tests as well
• Create a PR to pull feature branch into the upstream repo’s main branch, which triggers the CI pipeline for style and tests
• At least 1 other person must review the code before a PR can be approved and merged into upstream main
• There’s a separate CI pipeline for testing of publishing the packages to TestPyPI
• Releases to PyPI are currently done manually

At my work we use trunk based development, with mandatory review before merging (enforced by tooling). Part of the review is ensuring proper test coverage and it’s enhanced by static code analysis.

have you looked at Git Flow? Its pretty solid.

My team has a develop branch from which we branch feature branches. On it we commit our stuff and when we think its feature complete we build a snapshot version of it so that our QA can test it. Once that test was successful, and the code has been peer reviewed, it will be merged back onto develop.

PRs will be auto built so that the feature can be integrated and automated tested.