Introduction: Why PRs and Code Reviews Matter

In our previous article, we explored branch strategies. While organizing and managing branches well is important, the quality of team collaboration is ultimately determined during the process of merging those branches. This is where Pull Requests (PRs) and code reviews play a crucial role.

Honestly, when you first start developing, PRs and code reviews might feel like a hassle. You might think, "Why do I need to show my code to others?" or "Can't I just merge it directly?" However, as you gain experience, you'll realize just how valuable PRs and code reviews truly are.

A well-functioning code review culture plays a decisive role in catching bugs early, sharing knowledge, and maintaining consistent code quality. In this article, we'll cover everything from PR basics to effective code review methods and various GitHub features that you can apply immediately in your work.

1. What is a Pull Request?

1.1 The Concept of PR

A Pull Request (PR) is a request to merge the changes from your branch into another branch. Beyond simply combining code, it's also a communication tool that tells your team members, "I've made these changes, please review them."

GitLab calls it a Merge Request (MR), and Bitbucket also uses Pull Request. While the names differ, they're essentially the same concept.

1.2 The Role of PRs

  • Platform for Code Review: A space where team members review code and exchange feedback.
  • Change History Documentation: Records why changes were needed and how they were implemented.
  • Quality Gate: Can be configured so that merging is only allowed after passing automated tests and checks.
  • Knowledge Sharing: Learn new technologies and patterns by reviewing other team members' code.

1.3 Creating a PR

There are several ways to create a PR on GitHub.

# 1. Push your branch to remote
git push origin feature/user-profile

# 2-1. Create PR on GitHub web
# After pushing the branch, a "Compare & pull request" button appears on GitHub

# 2-2. Create PR with GitHub CLI
gh pr create --title "Add user profile feature" --body "Adding user profile functionality."

# 2-3. Create PR interactively
gh pr create

2. Writing Good PRs

2.1 Writing Good PR Titles

PR titles should be clear enough to understand the changes at a glance.

Good examples:

  • feat: add user profile page
  • fix: resolve session expiration error on login
  • refactor: improve payment module code structure
  • docs: add authentication section to API documentation

Examples to avoid:

  • fix - Cannot tell what was fixed
  • WIP - No information beyond "work in progress"
  • asdf - Meaningless title

2.2 Writing Effective PR Descriptions

The PR description (body) should contain essential information for reviewers to understand the changes.

## Changes
- Add user profile retrieval API endpoint (`GET /api/users/:id/profile`)
- Add profile update API endpoint (`PUT /api/users/:id/profile`)
- Implement profile image upload functionality

## Reason for Changes
Users needed the ability to manage their own profile information.
Previously, only administrators could modify user information,
but now users can manage their own profiles directly.

## How to Test
1. After logging in, go to the `/profile` page
2. Edit profile information and click save button
3. Refresh and verify that changes persist

## Screenshots
(Attach UI change screenshots if applicable)

## Checklist
- [x] Unit tests written
- [x] E2E tests passed
- [x] Documentation updated
- [ ] Performance testing (large image upload)

2.3 Managing PR Size

Smaller PRs are better PRs. Research shows that changes of around 200-400 lines receive the most effective reviews.

  • Benefits of small PRs: Faster reviews, higher bug detection rates, and easier rollbacks.
  • Problems with large PRs: Reviewers get tired, important issues are easily missed, and conflict probability increases.

Break large features into multiple small PRs. For example, "user profile feature" can be divided into:

  1. Database schema changes
  2. Backend API implementation
  3. Frontend UI implementation
  4. Testing and documentation

This way, it becomes 4 separate PRs.

3. Creating PR Templates

3.1 The Need for PR Templates

Creating templates for consistent PR formatting in your team has several benefits:

  • Prevents missing required information
  • Reduces time for reviewers to understand
  • Improves documentation quality across the team

3.2 How to Create PR Templates

Create a .github/pull_request_template.md file in the project root.

<!-- .github/pull_request_template.md -->

## Overview
<!-- Briefly explain what this PR solves -->

## Changes
<!-- List the main changes -->
-
-
-

## Related Issue
<!-- Link related issue numbers (e.g., Closes #123) -->

## Testing
<!-- Explain how to test -->

## Screenshots
<!-- Attach screenshots if there are UI changes -->

## Checklist
- [ ] Test code completed
- [ ] Documentation updated
- [ ] Code style guide followed
- [ ] Self-review completed

3.3 Using Multiple Templates

You can use different templates depending on PR type: features, bug fixes, documentation, etc.

.github/
  PULL_REQUEST_TEMPLATE/
    feature.md
    bugfix.md
    documentation.md

When creating a PR, you can select a specific template by adding ?template=feature.md to the URL.

4. The Importance of Code Review

4.1 The Purpose of Code Review

Code review provides value beyond simply finding bugs:

  • Early Bug Detection: Discover problems before they're deployed to production.
  • Knowledge Sharing: Team members understand and learn from each other's code.
  • Code Quality Maintenance: Maintain consistent coding styles and patterns.
  • Design Validation: Verify that the implementation approach is appropriate.
  • Team Culture Building: Create a culture of constructive feedback.

4.2 Statistical Effects of Code Review

Multiple studies have proven the effectiveness of code review:

  • Code review can detect 60-90% of bugs in advance.
  • Reviewed code has 30% lower defect density than non-reviewed code.
  • Time invested in code review saves 4-8 times the time spent fixing bugs.

5. Effective Code Review Methods

5.1 Preparation Before Review

For effective review, first understand the context:

  1. Read the PR description and related issues.
  2. Scan through the list of changed files.
  3. Understand the overall scope of changes.
  4. Plan which parts to focus on.

5.2 What to Check During Review

Functional Aspects:

  • Does it meet the requirements?
  • Are edge cases handled?
  • Is error handling appropriate?

Code Quality:

  • Is it readable and understandable?
  • Is there duplicate code?
  • Is naming clear?
  • Do functions/classes follow the single responsibility principle?

Performance and Security:

  • Are there potential performance issues?
  • Are there security vulnerabilities?
  • Is sensitive information not exposed?

Testing:

  • Is there sufficient testing?
  • Do tests cover meaningful cases?

5.3 Time Management for Reviews

Tips for effective review time management:

  • 200-400 lines at a time: Concentration decreases with longer reviews.
  • Within 60 minutes: Don't exceed 60 minutes per session.
  • First review within 24 hours: Context is lost when PRs are left too long.
  • Allocate fixed time: Dedicate a certain time each day for code review.

6. Giving Good Feedback

6.1 Principles of Constructive Feedback

The most important thing in code review is having a constructive attitude. Remember these principles:

  • Criticize the code, not the person: Use "Here..." instead of "This code is..."
  • Suggest in question form: "What do you think about this approach?" is better than "Do it this way"
  • Explain the reason: Don't just say "please change it" - explain why.
  • Mention good points too: Praise for well-done parts is also feedback.

6.2 Feedback Examples

Poor feedback:

Why did you write it like this? It's too complicated.

Good feedback:

This logic seems a bit complex. What do you think about
extracting it into a separate function for readability? For example:

function calculateDiscount(price, userType) {
  // discount logic
}

This way, when the discount policy changes later,
we'd only need to modify this function.

6.3 Categorizing Feedback

Marking the importance of feedback makes it easier for the author to understand priorities:

  • [Required] or [Blocker]: Must fix before merging
  • [Suggestion] or [Optional]: Something worth considering
  • [Question]: Question for understanding
  • [Praise] or [Nice!]: Well-done parts
  • [Nit]: Minor issues (typos, style, etc.)

7. Using GitHub's Review Features

7.1 Three Review States

When submitting a PR review on GitHub, you choose one of three states:

State Meaning When to Use
Comment General comment When questions or discussion is needed
Approve Approval When you think it's okay to merge
Request changes Change request When modifications are needed

7.2 Line-by-Line Comments

GitHub allows you to add comments directly to specific code lines. Using this feature:

  • It's clear exactly which part the feedback is about.
  • When code changes, the comment is automatically marked as "outdated".
  • You can select multiple lines to comment on.

7.3 Suggestion Feature

GitHub's Suggestion feature lets you show modification suggestions directly as code:

```suggestion
const userAge = calculateAge(birthDate);
```

The author can apply this suggestion with just one click, making it very convenient.

7.4 Batch Review Submission

Click the "Start a review" button to collect multiple comments and submit them all at once. Submitting comments one by one sends multiple notifications to the author, which can be disruptive.

8. Using Draft PRs

8.1 What is a Draft PR?

A Draft PR is a PR that is "still in progress and not ready for review." Introduced to GitHub in 2019, it's useful in various situations.

8.2 Draft PR Use Cases

  • Early feedback: When you want to verify the overall direction is correct
  • Work sharing: To let team members know "I'm working on this"
  • CI testing: When you want to run CI pipeline tests before merging
  • Incremental work: When working on something gradually over several days

8.3 How to Create a Draft PR

# Create Draft PR with GitHub CLI
gh pr create --draft --title "WIP: Payment system refactoring" --body "Work in progress."

# Or select "Create draft pull request" when creating PR on web

8.4 Changing from Draft to Ready

When work is complete, change the Draft PR to a reviewable state:

# Change state with GitHub CLI
gh pr ready

# Or click "Ready for review" button on web

9. Automated Review Settings

9.1 CODEOWNERS Configuration

Using a CODEOWNERS file, you can designate "owners" for specific files or directories. When those areas are changed, the designated people are automatically assigned as reviewers.

# .github/CODEOWNERS

# Default owners for entire codebase
* @tech-lead

# Frontend code
/frontend/ @frontend-team
*.jsx @frontend-team
*.tsx @frontend-team

# Backend code
/backend/ @backend-team
*.py @backend-team

# Infrastructure settings
/infra/ @devops-team
Dockerfile @devops-team
docker-compose.yml @devops-team

# Documentation
/docs/ @tech-writer
*.md @tech-writer

# Database migrations (requires special attention)
/migrations/ @dba @tech-lead

9.2 Branch Protection Rules

Using GitHub's Branch Protection feature, you can set required conditions before PR merging:

  • Require pull request reviews: Minimum 1-2 approvals required
  • Require status checks: CI tests must pass
  • Require CODEOWNERS review: Code owner approval required
  • Require conversation resolution: All comments must be resolved before merging
  • Require linear history: Maintain clean history

9.3 Automatic Reviewer Assignment

Using GitHub Actions, you can implement more complex automatic reviewer assignment logic:

# .github/workflows/auto-assign.yml
name: Auto Assign Reviewers

on:
  pull_request:
    types: [opened, ready_for_review]

jobs:
  assign-reviewers:
    runs-on: ubuntu-latest
    steps:
      - uses: kentaro-m/auto-assign-action@v1.2.5
        with:
          configuration-path: '.github/auto_assign.yml'
# .github/auto_assign.yml
addReviewers: true
addAssignees: author

reviewers:
  - reviewer1
  - reviewer2
  - reviewer3

numberOfReviewers: 2
reviewGroups:
  frontendReviewers:
    - frontend-dev1
    - frontend-dev2
  backendReviewers:
    - backend-dev1
    - backend-dev2

10. Building a PR Review Culture

10.1 Characteristics of a Healthy Review Culture

Characteristics of teams with good code review culture:

  • Fast feedback: PRs are not left unattended for more than 24 hours.
  • Respectful attitude: Feedback is constructive, not aggressive.
  • Learning-oriented: Everyone has the mindset of learning from reviews.
  • Clear standards: There are criteria for what constitutes acceptable code.
  • Balanced participation: Reviews are not concentrated on specific people.

10.2 Responsibilities of PR Authors

PR authors should also be considerate of reviewers:

  • Keep PR size small.
  • Write sufficient descriptions.
  • Do self-review first.
  • Submit PRs when tests pass.
  • Respond to feedback with an open mind.

10.3 Responsibilities of Reviewers

Reviewers should also approach reviews responsibly:

  • Start reviews promptly.
  • Focus and check carefully.
  • Provide constructive feedback.
  • Don't obsess over trivial things.
  • Acknowledge well-done parts.

Conclusion: PRs and Code Reviews Are the Team's Growth Engine

We've explored everything from PR writing to effective code review methods and various GitHub automation features. PRs and code reviews are not just procedures for merging code. They are core processes for the team to grow together and create better software.

It might feel cumbersome at first, but a well-established review culture provides tremendous value in the long run. Bugs decrease, code quality improves, and everyone on the team comes to understand the entire codebase. Most importantly, the feeling of "building together" strengthens team cohesion.

Apply what you learned today right away. Create PR templates, set up CODEOWNERS, and try using the Suggestion feature in your next review. Small changes can transform the entire team's collaboration culture.

In the next article, we'll explore GitHub Actions and CI/CD. If you continue following the Git & GitHub series, you'll be equipped with collaboration skills that you can immediately apply in real work.