# The Best Way to Do a Code Review on GitHub | LinearB Blog > Doing a code review on GitHub is part of the daily lives of many engineers. In this post, learn how to do it and how to avoid pitfalls. _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) / The Best Way to Do a Code Review on GitHub # The Best Way to Do a Code Review on GitHub ![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/code-review-on-github#carlos-schults) | March 25, 2022 ![pexels_christina_morillo_1181253_scaled_c9698ee37a](https://assets.linearb.io/image/upload/c_limit,w_2560/f_auto/q_auto/v1/pexels_christina_morillo_1181253_scaled_c9698ee37a?_a=BAVMn6ID0) GitHub was launched in 2008 and since then has become a massively popular platform for hosting source code, both for private and open-source projects. That’s why performing—or receiving—a code review on GitHub is part of the daily lives of many software engineers. That’s what this post is about: the right way to do a code review on GitHub. We’ll start with some fundamentals, briefly covering the importance of code reviews and how they relate to GitHub pull requests. Then, we’ll walk you through how the code review process works on GitHub, sharing tips on how to do it the best way. Before wrapping up, we’ll share some final thoughts and tips. Let’s dig in. ## Table of Contents * [Code Review on GitHub: The Fundamentals](#code-review-on-github) * [How to Do Code Reviews on GitHub the Right Way](#how-to-do-code-reviews-on-github-the-right-way) * [Fix Your Pull Requests and Reap the Benefits](#fix-your-pull-requests) ## Code Review on GitHub: The Fundamentals Before exploring the anatomy of a GitHub code review, let’s walk through some basics first. ### The Importance of Code Reviews When it comes to improving the quality of a codebase and [reducing technical debt](https://linearb.io/blog/7-simple-effective-steps-to-reduce-technical-debt/), there’s probably no technique more effective than code reviews—with automated testing being the honorable exception. We do have [another post on what code reviews are and why they matter](https://linearb.io/blog/what-is-code-review-why-its-important-for-code-quality/) as well as a post on [what you need (and don’t need) in your code review checklist](https://linearb.io/blog/code-review-checklist/), both of which you should check it out. Besides improving code quality, peer reviews also have another great advantage: they help to spread knowledge among team members. Through frequent code reviews, engineers can learn about different areas of the code, which helps their team achieve true collective code ownership, thus reducing their [bus factor](https://en.wikipedia.org/wiki/Bus%5Ffactor). This is especially important in a remote setting, where face-to-face knowledge transmission isn’t possible. ### Code Review != Pull Request With the importance of code reviews out of our way, there’s another point we need to discuss: the differences between a code review and a pull request. Sure, these two processes are related, but they’re not the same. It’s possible to use one or the other, or use both together—which we recommend. You could try using neither, but we definitely don’t recommend that. For instance, the following patterns are all possible: * Merging pull requests without review and then reviewing the code afterward * Using pair programming as a replacement for reviews—in my opinion, they don’t really substitute, but that’s another conversation * Performing code reviews even without using Git—in a previous job, we used Team Foundation Version Control and a Visual Studio plugin so we could have code reviews * Having pull requests on GitHub just for “auditing” purposes and merging them immediately after ### A Good Pull Request Process Makes Your Code Review Better Finally, since we do recommend you perform your code reviews during pull requests, it’s essential you understand the importance of a great pull request process. Speed is paramount, especially in a continuous integration/continuous software development paradigm. Small pull requests make it easier for the reviewer to review the code, [which reduces the time it takes for the pull request to be picked up and completed.](https://linearb.io/blog/pull-request-pickup-time/) The rule of thumb is: smaller pull requests and more pull request merges over larger pull requests and fewer merges. Paradoxically, speeding up development time also improves the quality of the shipped code! This is what LinearB’s CEO calls “the Bicycle Syndrome.” Having a standardized pull request process makes the lives easier for both reviewer and reviewee. Since both sides know what to expect, there’s less rework and less time wasted. Thankfully, you don’t have to create and execute on a pull request process all on your own. You can rely on code review tools designed to make the process easier and more effective. GitHub’s UI offers great features to facilitate code review, allowing the reviewer to compare diffs, leave comments on specific lines, and even suggest code changes on the spot. Pairing GitHub with LinearB’s [gitStream](https://linearb.io/dev/gitstream/) tool equips you with a powerful system that will be the basis for a successful code review process. With workflow automation and metrics, LinearB helps your teams keep pull request sizes small or ensure that they’re being thorough as they review requests. [](https://github.com/apps/gitstream-cm/installations/new) ## How to Do Code Reviews on GitHub the Right Way Do you know how a [code review](https://linearb.io/blog/code-review-checklist/) on GitHub works? How do you do it the right way? ### It All Starts With a Pull Request As I said earlier, pull requests and code reviews aren’t interchangeable terms, and even GitHub’s UI makes that distinction clear. However, since the pull request is a great “place” to centralize discussions about a proposed change, it makes sense to use it as the start of the code review process as well. Let’s start with a public repository like [this one](https://github.com/carlosschults/solid-octo-carnival/) I prepared for this post. To contribute to a public repo, you’d usually have to fork it, clone your fork locally, create a new branch for your changes, commit and push your changes, and finally open a pull request. That’s not necessarily hard, but it would make this post longer than needed, and this isn’t a GitHub or Git tutorial. Let’s make it easier. Go to the repo, click on the **README.md** file, and then click on the pencil icon on its right upper corner. You’ll then be able to edit the file as you wish. When you’re done, provide and title and description and click on **Propose Changes**. ![propose changes code review on github](https://assets.linearb.io/uploads/image-7.png) That will cause several things to happen: * GitHub will set up a new fork of the repository for you. * It will also create a new branch and commit the change you made to that branch. * Finally, it will submit a pull request from this newly-created branch. Oh, by the way, I’m keeping this repository online so that if you want to practice making pull requests, you can go there to actually create one and I’ll accept it. ### The Reviewer Analyzes the Changed Lines of Code So, I actually went there and created a pull request. It’s kind of weird to review a pull request that I myself sent, but _c’est la vie._ Here’s my view as the repo’s maintainer: ![github code review](https://assets.linearb.io/uploads/image-1-1-1024x705.png) As you can see, there’s quite a lot going on there. Let’s break it down: 1. The **Conversation** tab shows the comments both the reviewer(s) and the author left. There are currently no comments. 2. The **Commits** tab shows the individual commits contained in the pull request. 3. The **Checks** tab displays checks and verifications that can be done in a CI/CD process. You can set that up by using GitHub actions. 4. The **Files changed** tab displays the individual files touched by the change, so the reviewer can review them one by one. 5. The **Merge pull** request button allows me to close the pull request and incorporate its changes to the main branch. Going to the **Files changed** tab, this is what I see: ![github code review files changed](https://assets.linearb.io/uploads/image-2-2.png) The GitHub UI indicates very clearly: * which file was changed * what the change was * which portions of the file we’re seeing (indicated by the -1,3 and +1,3—that is, for the original (-) and changed (+) version we’re seeing three lines, starting at line 1). * the actual information that was deleted and replaced. ### The Reviewer Can Leave Single Comments or Initiate a “Formal” Review As a reviewer, there’s quite a lot of flexibility regarding how you handle the changes. For starters, you can leave general comments or add comments to specific files and lines. This is a general comment: ![github code review comment](https://assets.linearb.io/uploads/image-3-2.png) As you can see, you can choose to close the pull request with a comment, effectively rejecting the change. In this case, I’ll simply click on the **Comment** button and save my comment. I’ll now comment on a specific line. First, I’ll go to the **Files changed** tab. There, I can hover over the lines of both the old and new versions of the file, and a plus sign button appears: ![github code review comment on specific line](https://assets.linearb.io/uploads/image-4-1.png) By clicking on the button, I can leave a comment: It’s possible to add the comment as a “single comment” or to start a review. Single comments aren’t that exciting, so I’ll **Start a review**. Here’s what I see after pressing the button: ![github code review finish your review](https://assets.linearb.io/uploads/image-7-1.png) As you can see, there’s a **Finish your review** button I can use when I’m done reviewing the changes. In a real-world scenario, you’d typically finish the review after looking at all the changed files and leaving suggestions, questions, and observations as needed. After clicking on the button, you’ll see three options: 1. **Comment**. With this option, you just leave a comment without necessarily approving the changes. 2. **Approve**. This approves the changes. It doesn’t merge the branch and close pull request, though. 3. **Request** changes. You leave feedback that the author must address. ### The Author Can Reply to the Comments and Update the Code From now on, the process is relatively straightforward: * The author can reply to the comments, and other reviewers can jump on the conversation. * GitHub allows you to link to issues, commits, and even other pull requests. It’s also possible to mention users, inviting them to join the conversation. * The author can commit more changes and push them to their browser, and GitHub will automatically pick up those changes and update the pull request. ## Fix Your Pull Requests and Reap the Benefits As you read in this post, doing a code review on GitHub is, generally speaking, an easy and lightweight process. And, thanks to GitHub’s great UI, it’s also mostly intuitive. However, that doesn’t mean the pull request process isn’t without its pains. Reviewers suffer from large, complex pull requests. Authors suffer when their changes take a long time to be reviewed and merged. The whole team suffers because stuck PRs can lead to a number of problems, including conflicts. The good news is it doesn’t have to be this way. Pull requests can be fixed, and you can do it with the help of [automation tools](https://linearb.io/dev/gitstream/) that enable you and your team to be on top of your PRs. --- 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. --- At the end of the day, if you have a streamlined and standardized pull request process, your team will be able to make the most out of code reviews. So, before wrapping up, here are a few best practices regarding pull requests: * Keep your pull requests small and focused. * Start the pull request earlier; you don’t need to wait until you’re finished to start collecting feedback. * Add plenty of context to the pull request, including a well-written description, links to relevant resources, screenshots, and whatever you can use to help the reviewer understand the change. For more tips on pull requests, check out [our full blog post](https://linearb.io/blog/pull-request-best-practices-our-tips/) on the topic. Thanks for reading, and until the next time. ## 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": "The Best Way to Do a Code Review on GitHub", "url": "https://linearb.io/blog/code-review-on-github", "author": { "@type": "Person", "name": "Carlos Schults" }, "datePublished": "2022-03-25T11:05:00.000Z", "dateModified": "2022-03-25T11:05:00.000Z", "image": "https://assets.linearb.io/image/upload/v1720000000/pexels_christina_morillo_1181253_scaled_c9698ee37a.jpg", "publisher": { "@type": "Organization", "name": "LinearB", "logo": "https://assets.linearb.io/image/upload/v1777485755/linearb-logo-2026.png" }, "description": "Doing a code review on GitHub is part of the daily lives of many engineers. In this post, learn how to do it and how to avoid pitfalls.\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)