# Pull Request Best Practices: Our Tips | LinearB Blog > Pull requests often go wrong. Learn and adopt our list of pull request best practices so that doesn’t happen to your team. _This is a markdown rendering of a live HTML page on linearb.io, generated for AI/LLM consumption — it is not a markdown-only site. To get the full HTML page instead, request this URL with an explicit `Accept: text/html` header (no wildcard, no markdown preference)._ [Blog](https://linearb.io/blog) / Pull Request Best Practices: Our Tips # Pull Request Best Practices: Our Tips ![Photo of Carlos Schults](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/logo-mark-lg?_a=BAVMn6ID0) By [Carlos Schults](https://linearb.io/blog/pull-request-best-practices-our-tips#carlos-schults) | March 21, 2022 ![david_ballew_q_Yrto_E6_E_Sn_I_unsplash_scaled_4158f24b88](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/david_ballew_q_Yrto_E6_E_Sn_I_unsplash_scaled_4158f24b88?_a=BAVMn6ID0) [Reviewing pull requests](https://linearb.io/blog/what-is-a-pull-request/) is often really hard. But so is getting your code reviewed. Though there’s a lot of potential value in pull requests, you need to ensure you have the right code review process so you can reap the benefits without being slowed down by inefficiencies and harming your team’s morale. In this post, we’ll walk you through a list of pull request best practices intended to help your team get the best out of this process and make sure that everyone is writing good code. ## Table of Contents * [Pull Request Best Practices for the Reviewee](#pull-request-best-practices-for-the-reviewe) * [Pull Request Best Practices for the Reviewer](#pull-requests-best-practices-for-the-reviewer) * [General Best Practices](#general-best-practices) * [Standardize Your Pull Request Process](#standardize-your-pull-request-process) ## Pull Request Best Practices for the Reviewee Let’s open by focusing first on the reviewee’s side. ### Start the Process Early Good feedback is _early_ feedback. There’s no need for you to wait until you’re done with your change to submit a pull request. GitHub, GitLab, and Azure DevOps all allow you to create draft pull requests to collect early feedback. (By the way, GitLab calls “pull requests” “merge requests.”) With draft pull requests, you can start getting feedback on your changes way before merge time. You can then incorporate the suggestions you’ve got when it’s time to submit the actual pull request, improving the quality of your changes and making it more likely for your pull request to be accepted swiftly, speeding up the development process. ### Prefer Smaller Requests This is an unoriginal recommendation, and there’s a reason for that: it’s a tried-and-true piece of wisdom. When it comes to [pull request size](https://linearb.helpdocs.io/article/x1620txj8m-pull-request-size), keeping them small will make them more likely to be reviewed in a timely manner and in a comprehensive way. You would be surprised just how much this can [speed up](https://linearb.io/blog/why-code-quality-is-important-to-measure/#linearb-s-work-breakdown) the development cycle. Also, small pull requests are most likely to be focused, which brings us to the next point. ### Keep Pull Requests Atomic Keep pull requests atomic. That is, a pull request should refer to a single logical change. In other words, when someone asks about what your pull request does, you shouldn’t need to use the word “and” when replying. How does this mix with the concept of the Boy Scout Rule (i.e. the idea that you should always strive to leave the code better than you found it)? Let’s say that, while doing your task, you found some opportunities for improvement, such as removing [duplication](https://linearb.io/blog/code-duplication/), making some other [refactoring](https://linearb.io/blog/refactoring-in-agile/), or even adding a new unit test. Would performing one improvement inside the same pull request make it non-atomic? I don’t think so. In my experience, these types of improvements need to be performed ASAP. Otherwise, you run the risk of turning them into TODO items that will be inside the code for the rest of its life. Keeping pull requests small and atomic is easier said than done. In the flow of work, it is easy to fall into old habits and end up creating PRs that require time-consuming reviews. It can be hard just to remember to pause before you create a pull request to add a description! LinearB’s WorkerB bot will help you and your team improve by notifying you when a PR is too big. [![Nobody wants to review your huge pull request.](https://assets.linearb.io/uploads/pr-size-get-started-1024x497.png)](https://linearb.io/get-started/) Improve your code quality and developer workflow with smaller pull requests. [Get started with your free-forever LinearB account today.](https://linearb.io/get-started/) ### Add Plenty of Context to the Description Remember that your reviewer possibly knows nothing about your change. When filling a pull request’s description, try to do it in a way that answers the following questions: * **From a business perspective, why is this change important?** How does this move the team/organization closers to its goals? Linking the pull request to the ticket on GitHub/Jira/Azure Devops is an important part of answering that question. * **Does the change contain code that contradicts some best practices or conventions adopted by the team?** If there’s a legitimate reason for this exception, you should clearly document it in the description. * **Will people in the future be able to understand this change by reading the pull request’s description?** Remember that pull requests are also a form of documentation that can eventually be of invaluable help for other people, or even your future self. Have someone who’s as removed as possible from the issue review your pull request’s description to check that the description is truly easy to understand. If extremely necessary, short explanations about what the code does are fine. Ideally, the changes you made should be clear from the commit messages inside your PR. Lengthier explanations in prose are not only hard to follow, but also useless, since the diff is right there. As a general rule, make your description about the “why” and not the “how.” ## Pull Request Best Practices for the Reviewer Now, let’s cover the other side: best practices for reviewing pull requests. ### Don’t Be Quick to Assume Mistakes When reviewing a pull request, you shouldn’t act as a prosecutor but rather as a cooperator. Yes, you must protect the quality of the codebase, but you can do that by working together with the person who submitted the change. So, while reviewing the changes, don’t be quick to denounce what you perceive as mistakes. When you see something that doesn’t quite make sense, there could be a good reason for that. Instead of an accusatory mindset, adopt an attitude of humble curiosity. ![Instead of an accusatory mindset, adopt an attitude of humble curiosity.](https://assets.linearb.io/uploads/attitudehumble.png) ### When There Are Problems, Judge the Code and Not the Person Of course, every now and then you will find actual mistakes. When that happens, remember there’s a person on the other side of this process. They’re—most likely—doing their best and the mistake was made in good faith. So, remember to keep things as impersonal as possible when [pointing out problems](https://www.kazoohr.com/resources/library/positive-feedback-examples). “There’s a problem in this line” is better than “You made a mistake in this line.” Additionally, try to phrase your concerns as questions wherever possible, and also provide suggestions or even link to external resources—e.g. documentation or a blog post—when you think that’s helpful. ### Refuse the Pull Request If You Don’t Have the Bandwidth It’s not great when pull requests take a long time to be accepted and merged. When that happens, pull requests become a bottleneck in the software pipeline, engineers become either idle or forced into frequent context switches—which add to the [cognitive complexity](https://linearb.io/blog/cognitive-complexity-in-software/) of developing software—and the likelihood of merge conflicts go up. That’s why teams should try to reduce their [pull request review times](https://linearb.io/blog/reducing-pr-review-time/). As a reviewer, you can contribute to that by simply refusing to take a pull request if you don’t have the bandwidth. It’s better to be up front about it and let your coworker know your plate’s too full than to say “Yes,” and then take too long to review the pull request. Someone taking on a bunch of PRs is a sign that they could be overextending themselves and on a path to burnout. As an engineering lead, it can be hard to keep track bandwidth for each of your employees and intervene before they’re burnt out. Thankfully, with LinearB you can do exactly this and make sure that your team members are working at a sustainable pace. ![team health](https://assets.linearb.io/uploads/Group-1308_2x-1024x490.png) ### Loop in Someone Else if There’s Need Sometimes someone assigns you a pull request but you don’t feel you have the knowledge or experience to review it. Maybe you’re qualified to judge the architectural choices, but there are security concerns you think are better off reviewed by someone else. When that’s the case, don’t waste time getting that person on board. If you loop them as soon as you realize you need them, the likelihood of that critical portion of the changes being comprehensively reviewed in a timely manner goes up. ### Request Synchronous Communication When Needed Some pull requests are harder than others. You’ll often realize that a particular change is generating too much discussion. The back-and-forth isn’t productive, and you feel like asynchronous communication ceased to be the best medium for the exchange. Well, if that’s the case, reach out for another medium! If you feel the need—and there is the possibility—request synchronous communication. Jump on the text chat or even on a call if that makes sense. I’m all for asynchronous communication, but sometimes the quickest and most productive way to settle an issue is a live conversation. ## General Best Practices Before wrapping up, there are some bonus tips I’d like to share. ![Make good use of the automation at your disposal and keep reviewers for concerns that require human intelligence.](https://assets.linearb.io/uploads/requirehuman.png) ### Automate as Much as Possible There are many tools that can automate some of what could go in a pull request review. Things like static analyzers and [quality gates](https://linearb.io/blog/quality-gates/) can detect many types of problems, including adherence to coding standards, possible bugs, and potential security vulnerabilities. Make good use of the automation at your disposal and keep reviewers for concerns that require human intelligence. --- Want to learn how to implement custom dev workflow automation to cut code review time by up to 40%? [Watch this hands-on workshop](https://linearb.io/event/202303-gitstream-workshop/) to set up the free gitStream tool to automatically: ![:white_check_mark:](https://a.slack-edge.com/production-standard-emoji-assets/14.0/apple-medium/2705.png) Classify and route pull requests Add estimated review time to PRs Apply custom rules ![gitStream Workshop: Getting started with workflow automation](https://assets.linearb.io/uploads/LinearB-Youtube-Card_-Ofer-Guy-Gitstream-Workshop_-Getting-Started-With-Workflow-Automation-2-1024x576.png) gitStream product lead, Ofer Afias, will take you through a live demo of the three core functions when getting started with gitStream workflow automation to scale your team efficiently and improve your developer experience. --- ### The Main Branch Should Be Sacred If you’re practicing continuous integration/continuous deployment, then every successful merge of a feature branch into the **main** branch results in the application being deployed to production. However, even if you aren’t, **main** should always be in a state where it’s deployable. In other words, you should strive to keep all of the following requirements true: * At all times, code in **main** builds and all the tests pass. * It’s always safe to branch off of **main** when starting work on a new feature or fix. * The timeline of **main** should never be rewritten—i.e. **git push –force** to **main** is forbidden. * All production changes enter **main** through a pull request. ## Standardize Your Pull Request Process Pull requests offer great opportunities for the exchange of knowledge and experience and for the early identification and correction of issues, besides serving as documentation and enablers of traceability for the organization. But if not done right, pull requests can derail into sources of misery for the whole team. Hopefully, with the help of the tips you’ve read today, that won’t happen to your organization. Of course, your mileage may vary, and some of the tips might not work for you. That’s fine. What matters is that you standardize your pull request process to remove as much friction as you can, so the requests can serve as levers taking your engineering team to new heights. A great way to start standardizing your code review process is by establishing a review checklist. Check out [our post on what you need (and don’t need)](https://linearb.io/blog/code-review-checklist/) in your review checklist to get started. Thanks for reading. Want to improve your engineering processes at every level? [Get started with a LinearB free-forever account today!](https://linearb.io/get-started/) ## Improve developer productivity with LinearB Find us on [](https://www.linkedin.com/company/linearb) [](https://devinterrupted.substack.com/) ## Your next read [![Cover image for Slack turns channels into the context engine for agentic AI](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Post_Name_2400x1256_077524ba8b?_a=BAVMn6ID0)](https://linearb.io/blog/slack-jaime-delanghe-mcp-agent-context-channels) Workflow [Slack turns channels into the context engine for agentic AI](https://linearb.io/blog/slack-jaime-delanghe-mcp-agent-context-channels) Slack Chief Product Officer Jaime DeLanghe breaks down how channels serve as the foundational context layer for human-agent collaboration. Learn why Slack is... [![Cover image for Code generation is faster than ever, but shipping value isn't](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_AI_code_review_bottleneck_2400x1256_d73333ea46?_a=BAVMn6ID0)](https://linearb.io/blog/code-generation-faster-shipping-isnt) Workflow [Code generation is faster than ever, but shipping value isn't](https://linearb.io/blog/code-generation-faster-shipping-isnt) Your team writes more code than ever, but less reaches production. AI moved the bottleneck to code review. Here's how to measure it and unblock your pipeline.&n... [![Cover image for AI as a value multiplier: a human-centric approach to engineering leadership](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/Blog_Servant_Leadership_2400x1256_0cfd4e2a0c?_a=BAVMn6ID0)](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership) Workflow [AI as a value multiplier: a human-centric approach to engineering leadership](https://linearb.io/blog/ai-as-value-multiplier-human-centric-leadership) Super.com's Matt Culver explains why AI should be used as a value multiplier, not a cost-cutter, advocating for a human-centric approach to engineering... ## Structured data _Machine-readable metadata (JSON-LD) embedded in the page for search/AI context — not content rendered on the page itself._ ```json { "@context": "https://schema.org", "@type": "Organization", "name": "LinearB", "url": "https://linearb.io", "logo": "https://assets.linearb.io/image/upload/v1715628027/logo-mark-lg.svg", "description": "LinearB is the engineering productivity platform that helps engineering leaders prove AI is improving throughput without sacrificing delivery confidence, flow efficiency, or developer experience.", "sameAs": [ "https://www.linkedin.com/company/linearb" ], "award": [ { "@type": "Award", "name": "LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms", "dateAwarded": "2026", "awardedBy": { "@type": "Organization", "name": "Gartner®" } }, { "@type": "Award", "name": "Great Place to Work Certification", "dateAwarded": "2025-2027", "awardedBy": { "@type": "Organization", "name": "Great Place to Work" } }, { "@type": "Award", "name": "America's Best Startup Employers 2025", "dateAwarded": "2025", "awardedBy": { "@type": "Organization", "name": "Forbes Magazine" } } ], "hasCertification": [ { "@type": "Certification", "name": "SOC 1 Type 2" }, { "@type": "Certification", "name": "SOC 2 Type 2" }, { "@type": "Certification", "name": "GDPR Compliance certification" }, { "@type": "Certification", "name": "ISO 27001" } ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Pull Request Best Practices: Our Tips", "url": "https://linearb.io/blog/pull-request-best-practices-our-tips", "author": { "@type": "Person", "name": "Carlos Schults" }, "datePublished": "2022-03-21T13:56:09.000Z", "dateModified": "2022-03-21T13:56:09.000Z", "image": "https://assets.linearb.io/image/upload/v1720000000/david_ballew_q_Yrto_E6_E_Sn_I_unsplash_scaled_4158f24b88.jpg", "publisher": { "@type": "Organization", "name": "LinearB", "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png" }, "description": "Pull requests often go wrong. Learn and adopt our list of pull request best practices so that doesn’t happen to your team.\n" } ``` ## More on linearb.io ### Top navigation - [Book a Demo](https://linearb.io/book-a-demo) - [AI Code Reviews — Catch security risks, bugs, and spec mismatches](https://linearb.io/platform/ai-code-reviews) - [AI & Productivity Insights — See how AI tools affect cycle time and delivery speed](https://linearb.io/platform/ai-developer-productivity-insights) - [Measure AI Impact — Track AI adoption and tie it to delivery outcomes](https://linearb.io/use-case/measure-ai-impact) - [MCP Server — Chat with your data to spot patterns and boost output](https://linearb.io/platform/mcp-server) - [Resource Allocation — Cost initiatives and shape your investment strategy](https://linearb.io/platform/resource-allocation) - [Cost Capitalization — Capitalize engineering costs with audit-ready reports](https://linearb.io/platform/cost-capitalization) - [Dev Team Management — Set targets and tie throughput to business outcomes](https://linearb.io/platform/goals-and-reporting) - [DevOps Workflow Automation — Policy-based PR routing, approvals, and tests](https://linearb.io/platform/ai-workflow-governance) - [AI Powered Support — Unify AI and human code delivery in one clear view](https://linearb.io/use-case/ai-powered-support) - [Optimization — Surface friction with feedback and MCP insights](https://linearb.io/platform/developer-experience) - [Reporting — Spot what's working and what needs attention](https://linearb.io/use-case/measuring-developer-experience) - [Surveys — Turn developer feedback into actionable signals](https://linearb.io/platform/developer-surveys) - [Platform overview](https://linearb.io/platform/overview) - [Register now](https://linearb.io/event/engineering-productivity-gap) - [Customers](https://linearb.io/customers) - [Pricing](https://linearb.io/pricing) - [Why choose LinearB — Explore your data. Measure performance. Act to improve it.](https://linearb.io/why-linearb) - [APEX framework — The operating model for AI-era engineering teams](https://linearb.io/resources/apex-framework) - [Anti-FAQ — The questions other vendors won't answer](https://linearb.io/why-linearb/anti-faq) - [Security — Enterprise-grade compliance and zero code access](https://linearb.io/security) - [Build vs. buy — The hidden cost of building it yourself](https://linearb.io/resources/build-vs-buy) - [Dev Interrupted Podcast — Conversations with engineering leaders](https://linearb.io/dev-interrupted/podcasts) - [Reports & Guides — Deep dives on productivity and delivery](https://linearb.io/resources) - [Webinars — Expert sessions on productivity and AI](https://linearb.io/resources?category=workshops) - [Metrics Benchmarks — See how your engineering org stacks up](https://linearb.io/resources/software-engineering-benchmarks-report) - [Blog — Product updates and practical insights](https://linearb.io/blog) - [Help Center — Documentation, setup, and support](https://linearb.helpdocs.io) - [API Docs](https://docs.linearb.io/api-overview) - [Status](https://www.linearbstatus.com/) - [Integrations](https://linearb.io/integrations) - [LinearB is a Leader in the 2026 Gartner® Magic Quadrant™ for Developer Productivity Insight Platforms](https://linearb.io/resources/gartner-magic-quadrant-dpi-platforms-2026) - [Sign in](https://app.linearb.io/login) - [Enterprise](https://linearb.io/solutions/enterprise) - [Contact](https://linearb.io/contact-us) - [About us](https://linearb.io/about-us) - [Careers](https://linearb.io/careers) - [Service agreement](https://linearb.io/services-agreement) - [Privacy policy](https://linearb.io/privacy-policy) - [DPA](https://linearb.io/data-processing-agreement) - [Security FAQ](https://linearb.io/security-faq) - [Substack](https://devinterrupted.substack.com/) ### Footer _Additional links from the site footer, not repeated from the top navigation above._ - [GitHub](https://github.com/linear-b) - [LinkedIn](https://www.linkedin.com/company/linearb) - [Twitter](https://twitter.com/LinearB_Inc)