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.

Practice

1. What is the main purpose of a pull request in Git?

easy

A. To review and discuss code changes before merging

B. To delete a branch from the repository

C. To create a new repository

D. To reset the main branch to a previous commit

Solution

1. Step 1: Understand what a pull request does

   A pull request is used to propose code changes and get feedback before merging.

2. Step 2: Identify the main purpose

   It allows team members to review, discuss, and approve changes to keep code quality high.

3. Final Answer:

   To review and discuss code changes before merging -> Option A

4. Quick Check:

   Pull request = code review and discussion [OK]

Hint: Pull requests are for reviewing code before merging [OK]

Common Mistakes:

• Confusing pull requests with branch deletion
• Thinking pull requests create repositories
• Believing pull requests reset branches

2. Which Git command is used to push a new branch to the remote repository to start a pull request?

easy

A. git push origin main

B. git merge feature-branch

C. git pull origin feature-branch

D. git push origin feature-branch

Solution

1. Step 1: Identify the command to push a branch

   To push a new branch named 'feature-branch' to remote, use 'git push origin feature-branch'.

2. Step 2: Understand other options

   'git push origin main' pushes the main branch, 'git pull' fetches changes, and 'git merge' combines branches locally.

3. Final Answer:

   git push origin feature-branch -> Option D

4. Quick Check:

   Push new branch = git push origin branch-name [OK]

Hint: Push your feature branch with git push origin branch-name [OK]

Common Mistakes:

• Using git push origin main instead of feature branch
• Confusing git pull with git push
• Trying to merge before pushing the branch

3. Given this sequence of commands, what is the output of git status after step 4?

1. git checkout -b feature
2. touch newfile.txt
3. git add newfile.txt
4. git status

medium

A. On branch feature
Changes to be committed:
(new file: newfile.txt)

B. On branch feature
nothing to commit, working tree clean

C. On branch main
Changes to be committed:
(new file: newfile.txt)

D. fatal: not a git repository

Solution

1. Step 1: Analyze branch and file status

   After 'git checkout -b feature', you are on 'feature' branch. 'touch newfile.txt' creates a new file. 'git add newfile.txt' stages it.

2. Step 2: Understand git status output

   'git status' shows staged changes. Since newfile.txt is added, it appears under 'Changes to be committed' on branch 'feature'.

3. Final Answer:

   On branch feature Changes to be committed: (new file: newfile.txt) -> Option A

4. Quick Check:

   Added file staged = git status shows it [OK]

Hint: Staged files show under 'Changes to be committed' in git status [OK]

Common Mistakes:

• Assuming branch is still main
• Thinking staging clears changes
• Confusing untracked with staged files

4. You created a pull request but reviewers say your branch is behind main and has conflicts. What should you do to fix this?

medium

A. Delete your branch and create a new one

B. Force push your branch without updating

C. Merge main into your branch locally and resolve conflicts

D. Close the pull request and push directly to main

Solution

1. Step 1: Understand the conflict cause

   Your branch is behind main, so changes in main conflict with your branch.

2. Step 2: Fix conflicts by merging main

   Merge main into your branch locally using 'git merge main', resolve conflicts, then push updates to update the pull request.

3. Final Answer:

   Merge main into your branch locally and resolve conflicts -> Option C

4. Quick Check:

   Fix conflicts = merge main and resolve [OK]

Hint: Merge main into your branch to fix conflicts before pushing [OK]

Common Mistakes:

• Force pushing without resolving conflicts
• Deleting branch unnecessarily
• Pushing directly to main ignoring review

5. You want to ensure that every pull request is reviewed by at least two team members before merging. Which GitHub feature should you configure?

hard

A. Enable auto-merge on pull requests

B. Branch protection rules with required reviews

C. Set default branch to feature branch

D. Use git stash before pushing

Solution

1. Step 1: Identify the feature for enforcing reviews

   GitHub branch protection rules allow setting requirements like minimum number of reviewers before merging.

2. Step 2: Understand other options

   Auto-merge merges without review, changing default branch doesn't enforce reviews, and git stash is unrelated to pull requests.

3. Final Answer:

   Branch protection rules with required reviews -> Option B

4. Quick Check:

   Require reviews = branch protection rules [OK]

Hint: Use branch protection rules to require reviews before merge [OK]

Common Mistakes:

• Confusing auto-merge with review enforcement
• Changing default branch instead of protection rules
• Using git stash unrelated to reviews