Pull requests let you tell others about changes you've pushed to a branch in a repository in a [[Git]] repository. They can be used as a form of [[Peer code review]]. ## Tips for good Pull Requests  [^fn1] 1. **Short and sweet** — Nobody likes reviewing long PRs. It might not be fair, but ten 10-line pull requests will generally get reviewed faster than a single 100-line pull request. 2. **Limit scope** — One of the surest ways to confuse someone reading your change set is to mix concerns. Keep each PR focused on a single thing. One feature addition, one bug fix, or one refactor per PR! 3. **A good title** — Give your PR a meaningful _and accurate_ title. “Bugfix” doesn’t cut it. If someone has to divine the reason for your PR from the code, it’s a bad PR, and cognitive load (and thus wait times) go up! 4. **A good description** — Link to any relevant issues, stories, or other related changes in the description. If there’s anything at all unclear about your changes, explain it. Don’t make your reviewer guess, or leave a comment asking for basic information. [^fn1]: [4 tips to jump the PR review queue](https://jhall.io/archive/2021/03/17/4-tips-to-jump-the-pr-review-queue/) by [[@Jonathan Hall]]