The PR model discourages quick iterations. Effectively, it kills small refactorings and documentation improvements.
When PR approvals are obligatory, I build hierarchies of PRs or isolate refactorings in separate commits. Still, I feel it's too complicated, and often I choose not to do anything.
Rouan Wilsenach observes that not all code changes were born equal and require the same ceremony before the merge:
- "Ship" -- No PR. Small and safe changes that can go directly to the mainline.
- "Show" -- Open a PR and merge when automated tests pass. Then notify others to share your knowledge or ask for improvement advice. Btw, @gitlab has a magic checkbox "Merge when pipeline succeeds".
- "Ask" -- Open a PR and wait for the review. It works well when you're not sure you're taking the right approach and need a second opinion.
The code author has the freedom to decide in which category the code change falls, which sounds like unprecedented blasphemy in teams with trust issues.
On the other hand, I worked in a team where we naturally applied this approach. We felt incredibly productive and nothing bad happened.
Read more about this approach and how to make it work for your team.
Top comments (0)