# 5 Ways to Use GitHub to Approve a Pull Request | LinearB Blog > The GitHub approve pull request process is very flexible. You can approve PRs in several different ways. Learn 5 of them in this post. _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) / 5 Ways to Use GitHub to Approve a Pull Request # 5 Ways to Use GitHub to Approve a Pull Request ![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/github-approve-pull-request#carlos-schults) | May 8, 2024 ![roman_synkevych_w_X2_L8_L_f_Ge_A_unsplash_1_scaled_fb08807e1f](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/roman_synkevych_w_X2_L8_L_f_Ge_A_unsplash_1_scaled_fb08807e1f?_a=BAVMn6ID0) Pull requests are at the core of using GitHub, regardless of whether we’re talking about open-source or private projects. The [pull request](https://linearb.io/blog/what-is-a-pull-request/) process not only serves as a gate for code but also creates opportunities for discussion and exchange of knowledge. It also acts as documentation for code decisions. In this post, we’ll cover a very specific—yet very valuable—aspect of the pull request process: the different ways in which you can approve a pull request on GitHub. We’ll first explore some fundamentals, defining GitHub pull requests and offering a brief explanation about how they work. Then we’ll dive into different ways that you can approve GitHub pull requests. By the end of the post, you should know more about some of the options at your disposal and why some of those options represent anti-patterns you should be aware of. ## What Is a GitHub Pull Request? Let’s start with the “what” and “how” of GitHub pull requests (PRs). A pull request (called a “merge request” in GitLab) enables a contributor to request approval of their code changes before it is merged. The pull request process is a core tenet of how many teams work. It can serve as a protective barrier, guarding the quality of the code and helping to avoid merge conflicts, bugs, and the dreaded outage. Additionally, PRs create a nice opportunity for [reviewing the code](https://linearb.io/blog/automated-code-review/), discussions, and exchange of knowledge. If you use continuous integration and continuous deployment—[and you should](https://linearb.io/blog/what-is-continuous-merge)—PRs represent a nice spot for the implementation of [quality gates](https://linearb.io/blog/quality-gates/). Before a branch is merged into the mainline, you have the perfect opportunity for running automated tests and doing all kinds of useful checks. Finally, pull requests are a great piece of documentation. The discussions that take place while reviewing proposed changes become invaluable historical records for people in the future who will seek the context and motivation behind certain changes. ## How Does a Pull Request Work? For open-source projects, the pull request process typically works like this: * Find an open-source project you want to contribute to and fork it (i.e. create a copy of it using GitHub’s UI) * Clone the Git repository locally * Start working on your task or fix on a new branch—usually created off of main, though different projects might use different workflows * Push the changes to your own fork of the repository on GitHub–commonly known as a commit * Go to the original repository’s page and use the UI to create a pull request * Submit it to a peer for review and approval–once the pull request is opened, it cannot be approved by its creator. So, for open-source contributions, there will be at least three repositories you must be aware of: the original repo, your GitHub fork, and your local repository. This is called the “[fork and pull model](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model).” For private repositories, things are generally a bit more simplified. Instead of having to create your own fork, you’d typically have Git push access to the same repository. You’d then clone this repository. From this point on, the process would be the same. This is called the “[shared repository model,”](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#shared-repository-model) and it’s what small open-source teams and private companies use. ## How to Approve a Pull Request in GitHub As it turns out, the GitHub pull request process is quite flexible, accommodating many different styles and workflows. I’ll now walk you through several different ways in which you can [approve a PR](https://docs.gitstream.cm/automations/approve-tiny-changes/) on GitHub. ![github pull quote](https://assets.linearb.io/uploads/LinearB-6.png) ### (1) Approving Without Review Let’s start with the **worst possible** scenario: when people approve PRs without any kind of review. Except when it comes to the most trivial of changes (e.g., fixing typos or improving the formatting of some class), approving PRs without reviewing them is a terrible anti-pattern. While PRs should all be reviewed before approval/merging, it doesn’t necessarily need human intervention. [**gitStream**](https://docs.gitstream.cm/)–a free workflow automation tool–can [review and approve safe changes](https://docs.gitstream.cm/automations/approve-safe-changes/) (like docs updates) and free up resources to focus on more important and sensitive PR reviews–like [security updates](https://docs.gitstream.cm/automations/integrations/jit/review-jit-alerts/) or [sensitive files.](https://docs.gitstream.cm/automations/standard/review-assignment/review-sensitive-files/) PRs merged without reviews are signs of serious problems inside a team or organization. [PR size might be one of them.](https://linearb.helpdocs.io/article/x1620txj8m-pull-request-size?%5Fgl=1%2A1u969l1%2A%5Fga%2ANzA4ODEyMDQ2LjE3MDc0MTc4Nzk.%2A%5Fga%5FF1R8XM8C78%2AMTcxNTEyMzM0MS4yNzUuMS4xNzE1MTI1Mjc4LjQyLjAuMA..%2A%5Fgcl%5Faw%2AR0NMLjE3MDk5MzQzODQuQ2p3S0NBaUFpNnV2QmhBREVpd0FXaXlSZGhFYnVYTEREcFNaVnZiUmR0UGJ1UkxfVVdjNVJrdUJnTG9KNEhZWkVUdTI2ZnZKYm1ZRXRSb0N1UVVRQXZEX0J3RQ..%2A%5Fgcl%5Fau%2AOTc0NzY1NjI2LjE3MDc0MTc4NzkuNTA5MzY5NDMuMTcxNTEwMDg2MC4xNzE1MTAwODYw) Large pull requests are hard for the reviewers, so many might simply give up and just accept them by default. Lack of team conventions and strong governance models also come to mind—after all, it shouldn’t even be possible to merge PRs without review. Large PRs also negatively impact [cycle time](https://linearb.io/blog/cycle-time) as they take longer to review–so they sit idle longer. [LinearB provides real-time alerts](https://linearb.io/book-a-demo) to notify you and your team when large PRs are created. Teams can also use this alerting to remind the team of any goals set around this metric–helping the team adopt good habits and keep PRs small. In addition to alerts, teams can [use gitStream to automatically apply labels](https://docs.gitstream.cm/examples/) to PRs that provide additional context (like estimated review time) to help reviewers prepare, prioritize their day, and minimize the cognitive load. [![Identify your team rebels. Schedule a demo of WorkerB alerts for PRs merged without review.](https://assets.linearb.io/uploads/Merged-Without-Review-1024x497.png)](https://linearb.io/get-started/) Improve your code review process with alerts for PRs merged without review. [Get started with our free-forever account today!](https://linearb.io/get-started/) If a PR is approved without review, [there are ways to deal with that](https://linearb.helpdocs.io/article/o33iwr05u2-how-to-handle-material-pull-request-merged-w-o-review-or-superficial-review), which include [reverting](https://linearb.io/blog/easily-revert-git-pull-requests/) the PR or even performing a review after the fact. ### (2) Closing Without Approving It’s also possible for a reviewer to close a PR without approving it. This might sound harsh, but it’s actually better for the health of the codebase than blindly approving all PRs. In the context of open-source projects, maintainers will often close PRs that don’t follow the contributing guidelines of the project. They might even use bots to automatically check some requirements and close the PRs that don’t adhere to them. In the context of private projects, outright closing PRs is rare. Typically, at least some discussion will take place before the submissions are either accepted or rejected. ![Using GitHub's branch protection settings, you can configure several different options for your repos.](https://assets.linearb.io/uploads/LinearB-7.png) ### (3) Having Required Reviewers Using GitHub’s branch protection settings, you can configure several different options for your repos. Among them, you can determine that a given number of approvals is needed for PRs to be approved. You could also [use gitStream to mandate that certain PRs have to be reviewed by certain teams.](https://docs.gitstream.cm/automations/assign-reviewers-by-directory/) For instance, you might want to enforce a rule that the branch needs at least two approving reviews to merge a pull request. ### (4) Accepting After Offering Feedback On GitHub, there are some different forms of feedback you can provide: * **General comments:** These are PR-level comments, grouped in the “conversation” tab of the PR page * **File comments:** You can add individual comments to any changed lines of any altered file * **Review**: This is an “official” review, which can contain one or more comments. As the following image shows, when giving feedback on lines, you can choose to add a single comment or start a review: ![github review example](https://assets.linearb.io/uploads/2022-02-28-20_37_30-Window.png) When you decide to submit a review, you must provide a comment with one of the following three statuses: * **Comment:** This is a comment that doesn’t explicitly approve or reject the changes * **Approve:** This feedback closes and accepts the PR * **Request changes:** A great use case is if a [deprecated component](https://docs.gitstream.cm/automations/change-deprecated-components/) is used--This type of feedback keeps the PR open while it’s not addressed ![positive review](https://assets.linearb.io/uploads/review.png) To act upon a piece of feedback, the person submitting the code will typically: * Go back to their local repository * Perform the necessary changes * Commit and push those changes GitHub automatically picks up the changes and updates the PR page. This style of approving merges typically leads to higher-quality code. Setting thresholds for the number of comments per PR would have similar code quality benefits to setting a rule that a branch needs two approvals to merge a PR. With LinearB, you can set customized thresholds, and WorkerB will warn your team when a PR with a basic review is about to be merged. Then you can measure your team’s review depth over time. We’ve found that as review depth increases, code quality increases, [cycle time](https://linearb.io/blog/cycle-time/) improves and unplanned interruptions caused by code churn are reduced. All of this allows your devs to spend more time on new features (value creation). Avoid superficial LGTM reviews. Use Team Goals + WorkerB to reinforce good habits around review depth. [Get started today!](https://linearb.io/get-started/) ### (5) Testing the Branch Locally This is probably the most labor-intensive style of approving PRs. Sometimes the change is so complex or critical that the reviewer feels the need to pull the branch to merge it and [test it locally](https://www.architect.io/blog/2022-08-09/test-environment-guide/). There might be the need to solve merge or logical conflicts, fix broken tests, or perform other types of corrections. However, best practices are that testing and code review ought to be two distinct activities. If the reviewer feels the need to do this intensive form of review, it’s a troubling sign. ## Why Are Certain Approval Processes Better? The pull request process is at the core of the software development lifecycle. However, it can derail into anti-patterns if you don’t give it the care it deserves. This post covered some of the styles of review you can adopt when approving pull requests. As you’ve seen, most of them represent some kind of anti-pattern. Our research shows that the perfect PR is the one that’s small, focused, generates some amount of healthy discussion, and doesn’t take too long to be reviewed and merged. If you’ve discovered that your cycle time is too high and the culprit is your pull requests process, or specifically your PR review time, be wary of how you encourage your team to improve these metrics. It’s not merging without review, and it’s not superficial, less thoughtful review comments. It is by [gaining visibility into and addressing leading and lagging indicators metrics](https://linearb.io/resources/engineering-leader-guide-to-building-a-metrics-program) and then working to improve them with[ programmable workflows.](https://linearb.io/resources/engineering-leader-guide-to-programmable-workflows) ## 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": "5 Ways to Use GitHub to Approve a Pull Request", "url": "https://linearb.io/blog/github-approve-pull-request", "author": { "@type": "Person", "name": "Carlos Schults" }, "datePublished": "2022-03-15T15:48:44.000Z", "dateModified": "2024-05-08T07:00:00.000Z", "image": "https://assets.linearb.io/image/upload/v1720000000/roman_synkevych_w_X2_L8_L_f_Ge_A_unsplash_1_scaled_fb08807e1f.jpg", "publisher": { "@type": "Organization", "name": "LinearB", "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png" }, "description": "The GitHub approve pull request process is very flexible. You can approve PRs in several different ways. Learn 5 of them in this post." } ``` ## 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)