Mastering Git Rebase: A Real-World Case Study in Pull Request Management

By Thanh Phong Le
July 30, 2025

The Challenge: When Progressive Learning Meets Code Review

While working on a Node.js course with weekly assignments that built upon each other, I encountered a common but complex Git workflow challenge. My pull request for Week 4's Express middleware assignment included all 41 files from previous weeks, making it difficult for reviewers to focus on the actual Week 4 changes. The reviewer rightfully asked: "Were you able to merge your changes? I noticed that the Week4 PR still includes files from the past lessons."

Understanding the Root Cause

The issue stemmed from how educational projects naturally evolve versus how Git pull requests are typically structured:

# Initial branch structure (each week built on the previous)
week1: Basic Node.js fundamentals
week2: week1 + Async patterns  
week3: week2 + Express setup
week4: week3 + Middleware & API

When creating a PR from week4 to main, GitHub showed all accumulated changes from weeks 1-4, not just the Week 4 additions.

Diagnostic Commands That Revealed the Problem

# 1. Check what commits would be included in the PR
git log origin/main..HEAD --oneline
# Output showed all 4 weeks of commits:
b000c9e Implement Week 4 Express middleware and people API
b27c830 Add .gitignore to exclude IDE files
c575ffb Setup Express server
7cacc9a Complete week 2 Node.js assignment
1d720a5 answers for lesson 1

# 2. Verify what changes GitHub sees in the PR
gh pr view 4 --json additions,deletions,changedFiles
# Result: 41 files changed with thousands of lines

# 3. Check which files are included
gh pr diff 4 --name-only | head -20
# Showed files from all previous weeks

The Solution: Sequential Merge with Rebase Strategy

The solution involved systematically merging each week's PR in order, then rebasing subsequent branches to create focused pull requests.

Step 1: Merge Week 1 (Already Approved)

gh pr merge 1 --repo ltphongssvn/node-express-course --merge

Step 2: Rebase Week 2 onto Updated Main

git fetch origin
git checkout week2
git rebase origin/main
git push --force-with-lease origin week2

Step 3: Verify Changes and Merge

# Confirm PR now shows only Week 2 changes
gh pr view 2 --json additions,deletions,changedFiles
# Result: Reduced from 2,536 to 497 additions, only 8 files

gh pr merge 2 --merge

Step 4: Repeat for Remaining Weeks

The same pattern was applied to weeks 3 and 4, each time creating cleaner, more focused pull requests.

Key Learnings and Professional Impact

1. Git's Intelligence in Handling Duplicate Commits

During rebasing, Git automatically detected and skipped previously applied commits:

warning: skipped previously applied commit 7cacc9a

2. The Power of --force-with-lease

Unlike dangerous --force, this command ensures we only overwrite branches in their expected state:

git push --force-with-lease origin branch-name

3. Transformation Results

The final Week 4 PR went from:

• Before: 41 files, thousands of lines across all weeks
• After: 3 files, 97 additions - just the middleware and API implementation

Real-World Applications

This workflow is essential for:

• Microservices Development: Managing feature dependencies across services
• Educational Content: Creating clear learning progressions
• Open Source Contributions: Maintaining clean commit histories
• Team Collaboration: Enabling focused code reviews

Tools and Commands for Debugging PR Issues

# Essential diagnostic commands
git log origin/main..HEAD --oneline  # See what commits will be in PR
git fetch origin                      # Update local knowledge of remote
gh pr list --state open              # View all open PRs
gh pr diff PR# --name-only           # See files changed in specific PR
git branch -vv                       # View branch tracking relationships

Conclusion

Managing dependent pull requests requires understanding both Git's mechanics and GitHub's PR calculation system. By mastering rebase workflows, we can transform overwhelming, cumulative PRs into focused, reviewable contributions.

This skill distinguishes developers who not only write good code but also facilitate effective collaboration through thoughtful version control practices. The ability to reorganize Git history isn't just about technical proficiency—it's about respecting reviewers' time and creating maintainable, understandable codebases that tell the story of how complex systems evolve.

If you enjoyed this article, you can also find it published on LinkedIn and Medium.