A Meritocracy of Pull Requests
summary
Argues that pull requests succeed on concrete hygiene: keep them small, close or split giant rewrites, and prefer the reviewer to merge to avoid stale WIP and reduce merge conflicts. Recommends concrete git commands and workflows: use git rebase/interactive-rebase for tidy history, resolve conflicts via git status and git merge --abort when stuck, configure a git diff tool, and enforce CI and PR templates so merges only happen after tests pass. Practical rules: reviewer does the merge, small pull requests are safe, run the code before approving.
AI-written summary · about
chapters (9)
- 0:00Introduction and speaker background
- 1:48What is a meritocracy of pull requests
- 6:03Closing pull requests: when and why
- 11:47Merging code: mechanics and best practices
- 22:21Rebasing and squashing branches
- 33:09Reviewing pull requests as a superpower
- 46:48Giving feedback and communication in PRs
- 51:28Opening pull requests with care
- 55:20Conclusion and resources
related talks
11mPull Requests: Merge With Your Team
28mPull Requests: Merging good practices into your project
38mPull Requests and Reviews for Good
21mA Guide to Perfecting Pull Requests
29mThe Art of Humanizing Pull Requests (PR’s)
16mAn unpopular opinion: Get rid of Pull Requests!
21mContinuous Improvements of The Code Review Process
26mThe Art of Humanizing Pull Requests