Code review in pull requests in Git - Deep Dive

Overview - Code review in pull requests

What is it?

Code review in pull requests is a process where developers ask their teammates to check their code changes before merging them into the main project. A pull request is a request to add new code or updates, and the review helps catch mistakes, improve quality, and share knowledge. It is like asking a friend to proofread your work before final submission. This process happens on platforms like GitHub, GitLab, or Bitbucket.

Why it matters

Without code reviews in pull requests, bugs and errors can easily slip into the main project, causing problems for users and making fixes harder later. It also slows down team learning and collaboration. Code reviews help maintain high-quality software, reduce mistakes, and spread understanding among team members, making the project healthier and easier to maintain.

Where it fits

Before learning code review in pull requests, you should understand basic git commands like commit, branch, and push. After mastering this, you can learn advanced collaboration workflows, continuous integration, and automated testing that work together with pull requests to improve software delivery.

Mental Model

Core Idea

Code review in pull requests is a team checkpoint where peers examine proposed code changes to ensure quality and shared understanding before merging.

Think of it like...

It's like submitting a draft of a group project to your classmates for feedback before handing it in to the teacher, so everyone agrees it's good and correct.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Developer A   │──────▶│ Pull Request  │──────▶│ Reviewers     │
│ writes code   │       │ created on    │       │ comment,      │
│ and pushes    │       │ platform      │       │ approve, or   │
│ branch       │       │ (GitHub etc.) │       │ request changes│
└───────────────┘       └───────────────┘       └───────────────┘
                                   │
                                   ▼
                          ┌─────────────────┐
                          │ Merge to main   │
                          │ branch if       │
                          │ approved        │
                          └─────────────────┘

Build-Up - 6 Steps

1

Foundation

Understanding Pull Requests Basics

Concept: Learn what a pull request is and how it fits into git workflows.

A pull request is a way to ask to merge your code changes from one branch into another, usually from a feature branch into the main branch. It shows the differences (diffs) between branches and allows discussion before merging. Platforms like GitHub provide a web interface to create and manage pull requests.

Result

You can create a pull request that shows your code changes and invites others to review them.

Knowing what a pull request is sets the stage for understanding how teams collaborate and maintain code quality.

2

Foundation

Basic Git Branching and Committing

Concept: Understand how to create branches and commit changes to prepare for pull requests.

Use git commands to create a branch: git checkout -b feature-branch. Make code changes and save them with git add and git commit. Push the branch to the remote repository with git push -u origin feature-branch. This branch is the source for your pull request.

Result

You have a separate branch with your changes pushed to the remote repository, ready for a pull request.

Mastering branching and committing is essential because pull requests depend on comparing branches.

3

Intermediate

Reviewing Code Changes Effectively

🤔Before reading on: do you think code review is only about finding bugs or also about improving code style and sharing knowledge? Commit to your answer.

Concept: Learn what to look for during a code review beyond just bugs.

Reviewers check for correctness, readability, style consistency, performance, and potential bugs. They also suggest improvements and ask questions to understand the code better. Comments can be inline on specific lines or general. Reviewers approve the pull request when satisfied or request changes if needed.

Result

Code reviews improve code quality and team understanding before merging.

Understanding the broad goals of code review helps you give and receive better feedback, improving the whole project.

4

Intermediate

Using Pull Request Tools and Features

🤔Before reading on: do you think pull request platforms only show code diffs or also support discussions, checks, and automation? Commit to your answer.

Concept: Explore the features of pull request platforms that support reviews.

Platforms like GitHub show code diffs, allow inline comments, track review status, and integrate automated checks like tests or linters. They notify team members and keep a history of discussions. You can assign reviewers, label pull requests, and link issues.

Result

You can use platform tools to manage and streamline the review process.

Knowing platform features helps you use pull requests efficiently and leverage automation.

5

Advanced

Handling Review Feedback and Iterations

🤔Before reading on: do you think you must create a new pull request for every change after feedback or update the existing one? Commit to your answer.

Concept: Learn how to respond to review comments and update your pull request.

When reviewers request changes, you update your code locally, commit the fixes, and push to the same branch. The pull request updates automatically. This cycle continues until reviewers approve. You can also discuss disagreements or clarify questions in comments.

Result

Pull requests evolve through feedback until ready to merge.

Understanding this iterative process prevents confusion and keeps collaboration smooth.

6

Expert

Advanced Review Strategies and Automation

🤔Before reading on: do you think code review can be fully automated or always needs human judgment? Commit to your answer.

Concept: Explore how teams combine human reviews with automation for efficiency and quality.

Teams use automated tools to run tests, check code style, and scan for security issues on pull requests. These tools provide quick feedback and reduce reviewer workload. However, human judgment is essential for design, logic, and maintainability. Experts also use review checklists, assign specialized reviewers, and enforce branch protection rules to ensure quality.

Result

A balanced approach of automation and human review improves speed and quality in production.

Knowing the limits and strengths of automation helps design effective review workflows.

Under the Hood

When a pull request is created, the platform compares the source branch with the target branch to generate a diff of code changes. It stores this diff and metadata like comments and approvals. Reviewers interact with this stored data via the web interface or APIs. Automated checks trigger on the pull request events, running tests or analysis in isolated environments. Once approved, the platform merges the source branch into the target branch, updating the main codebase.

Why designed this way?

Pull requests were designed to provide a clear, trackable, and collaborative way to review code changes before merging. This avoids direct pushes to main branches, reducing errors and conflicts. The design balances human collaboration with automation, enabling teams to maintain quality and speed. Alternatives like direct commits or email patches lacked this structured workflow and visibility.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ Developer     │──────▶│ Pull Request  │──────▶│ Reviewers     │
│ pushes branch │       │ platform      │       │ comment &     │
│               │       │ generates diff│       │ approve       │
└───────────────┘       └───────────────┘       └───────────────┘
                                   │
                                   ▼
                          ┌─────────────────┐
                          │ Automated checks│
                          │ run tests, style│
                          └─────────────────┘
                                   │
                                   ▼
                          ┌─────────────────┐
                          │ Merge if approved│
                          │ update main      │
                          └─────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Is code review only about finding bugs? Commit yes or no before reading on.

Common Belief: Code review is just about catching bugs before code goes live.

Reality: Code review also improves code readability, enforces style, shares knowledge, and helps maintain long-term quality.

Why it matters: Focusing only on bugs misses opportunities to improve team skills and code maintainability.

Quick: Do you think automated tools can replace human code review? Commit yes or no before reading on.

Common Belief: Automated tests and linters can fully replace human code review.

Reality: Automation helps but cannot judge design, logic, or user experience, which require human insight.

Why it matters: Relying only on automation risks poor design and hidden issues that humans would catch.

Quick: Should you create a new pull request for every small fix after feedback? Commit yes or no before reading on.

Common Belief: Every change after review requires a new pull request.

Reality: You update the existing pull request by pushing new commits to the same branch.

Why it matters: Creating multiple pull requests for one feature causes confusion and review overhead.

Quick: Is it okay to merge pull requests without approvals if you trust the author? Commit yes or no before reading on.

Common Belief: If you trust the developer, you can merge without formal review approvals.

Reality: Skipping reviews risks introducing unnoticed errors and reduces team knowledge sharing.

Why it matters: Trust alone cannot replace the safety net and collaboration benefits of code reviews.

Expert Zone

1

Reviewers often look for code simplicity and future maintainability, not just correctness.

2

Small, focused pull requests get reviewed faster and with higher quality than large, complex ones.

3

Branch protection rules can enforce review policies automatically, preventing merges without approvals or passing checks.

When NOT to use

In very small solo projects or quick experiments, formal pull request reviews may slow down progress unnecessarily. Instead, direct commits or informal peer checks can be used. For urgent hotfixes, bypassing full review with post-merge review might be acceptable.

Production Patterns

Teams use pull request templates to standardize information, assign specific reviewers based on expertise, integrate CI/CD pipelines to run tests automatically, and use bots to enforce rules and remind reviewers. Large projects break features into multiple small pull requests to keep reviews manageable.

Connections

Continuous Integration (CI)

Pull requests often trigger CI pipelines that run automated tests and checks.

Understanding pull requests helps grasp how CI ensures code quality before merging.

Peer Review in Academic Publishing

Both involve experts reviewing work before acceptance to ensure quality and correctness.

Seeing code review as a peer review process highlights its role in maintaining standards and sharing knowledge.

Quality Control in Manufacturing

Code review acts like a quality checkpoint to catch defects before products reach customers.

Recognizing code review as quality control helps appreciate its importance in preventing costly errors.

Common Pitfalls

#1 Ignoring small comments and rushing to merge.

Wrong approach:

Merge pull request immediately after one approval without addressing all comments.

Correct approach:

Address all reviewer comments with fixes or explanations before merging.

Root cause:

Misunderstanding that all feedback improves code quality, not just approval status.

#2 Creating huge pull requests with many unrelated changes.

Wrong approach:

Push a single pull request that changes multiple features and fixes unrelated bugs.

Correct approach:

Split changes into small, focused pull requests each addressing one feature or fix.

Root cause:

Not realizing that large pull requests are hard to review and increase errors.

#3 Skipping reviews because the author is senior or trusted.

Wrong approach:

Merge code from senior developers without review to save time.

Correct approach:

Require reviews for all pull requests regardless of author to maintain quality and knowledge sharing.

Root cause:

Assuming trust replaces the benefits of collaborative review.

Key Takeaways

Code review in pull requests is a collaborative checkpoint to improve code quality and share knowledge before merging.

Pull requests compare branches and provide a platform for discussion, feedback, and automated checks.

Effective reviews look beyond bugs to include readability, style, and maintainability.

Updating the same pull request with fixes after feedback keeps the process smooth and clear.

Combining human review with automation balances speed and quality in professional workflows.