DEV Community

cycy
cycy

Posted on

The Git Workflow That Will Make Your Code Reviews Actually Enjoyable 🔥

Stop creating monster PRs that make reviewers cry. Here's how senior developers structure their work for lightning-fast reviews and zero merge conflicts.

TL;DR - The Commands You Actually Need 🚀 

# 1. Stack your branches
git checkout feature/foundation
git checkout -b feature/api-layer

# 2. After base PR merges
git checkout feature/api-layer
git rebase main
git push --force-with-lease

# 3. Profit (seriously, that's it)
Enter fullscreen mode Exit fullscreen mode

Why Your Current Workflow Is Broken (And How to Fix It) 💔

The Problem: You're probably doing this:

  • ✗ 47 files changed, 2,341 lines added
  • ✗ Reviewer gives up after 10 minutes
  • ✗ Merge conflicts from hell
  • ✗ "LGTM" (they didn't actually review)

The Solution: Branch stacking turns this into:

  • ✅ 3-5 focused PRs
  • ✅ Each PR = 1 clear concept
  • ✅ Reviewers actually understand your code
  • ✅ Merges happen in minutes, not days

The Stacking Strategy That Actually Works 🎯

Your Branch Hierarchy 

main
└── feature/database-setup
    └── feature/api-endpoints  
        └── feature/authentication
            └── feature/error-handling
Enter fullscreen mode Exit fullscreen mode

Your PR Stack

  • PR #1: feature/database-setup → main
  • PR #2: feature/api-endpoints → feature/database-setup
  • PR #3: feature/authentication → feature/api-endpoints
  • PR #4: feature/error-handling → feature/authentication

Step-by-Step: Master the Art of Stacking 🛠️

Phase 1: Create Your Stack 

# Start with your foundation
git checkout main
git checkout -b feature/database-setup
# ... do work, commit, push ...

# Stack the next feature
git checkout feature/database-setup
git checkout -b feature/api-endpoints
# ... do work, commit, push ...

# Keep stacking
git checkout feature/api-endpoints  
git checkout -b feature/authentication
# ... you get the idea ...
Enter fullscreen mode Exit fullscreen mode

Phase 2: Open Strategic PRs

GitHub/GitLab UI:

  • Set base branch to your previous feature (not main!)
  • PR shows only the new changes
  • Reviewers see clean, focused diffs

Phase 3: The Rebase Dance (When PRs Merge)

When your foundation PR merges:

# Switch to your next branch
git checkout feature/api-endpoints

# Rebase onto latest main  
git rebase main

# Update remote (required after rebase)
git push --force-with-lease
Enter fullscreen mode Exit fullscreen mode

✨ Magic happens: Your PR automatically updates to show clean diff against main

Pro Tips That Separate Juniors from Seniors 🎓

🔥 Hot Take: Name Your Branches Like a Storyteller 

# Boring ❌
feature/updates
feature/fixes

# Engaging ✅  
feature/user-auth-foundation
feature/payment-processing-core
feature/notification-system
Enter fullscreen mode Exit fullscreen mode

⚡ The Force-Push That Won't Break Everything

Always use --force-with-lease instead of --force:

git push --force-with-lease  # ✅ Safe
git push --force            # ❌ Dangerous
Enter fullscreen mode Exit fullscreen mode

🎯 The Golden Rules

  1. One concept per branch - If you can't explain it in one sentence, split it
  2. Stack logically - Each branch should build on the previous
  3. Rebase, don't merge - Keep that history clean
  4. Small commits - Future you will thank present you

Troubleshooting: When Things Go Wrong 🚨

"My rebase failed with conflicts!" 

# During rebase conflicts:
# 1. Fix conflicts in your editor
# 2. Add resolved files
git add .
# 3. Continue rebase
git rebase --continue
Enter fullscreen mode Exit fullscreen mode

"I accidentally rebased the wrong branch!" 

# Find your previous commit
git reflog

# Reset to before the rebase
git reset --hard HEAD@{3}  # adjust number as needed
Enter fullscreen mode Exit fullscreen mode

"My PR shows too many commits!"

You probably set the wrong base branch. Change it in the PR settings.

The Results Speak for Themselves 📊

Before Stacking:

  • Average review time: 2-3 days
  • Merge conflicts: Weekly nightmare
  • Code quality: "It works, ship it"

After Stacking:

  • Average review time: 2-3 hours
  • Merge conflicts: Virtually eliminated
  • Code quality: Actually gets reviewed properly

Quick Reference Card (Bookmark This!) 📌

Task Command
Create stacked branch git checkout previous-branch && git checkout -b new-branch
After PR merges git checkout your-branch && git rebase main
Update remote git push --force-with-lease
Fix rebase conflicts git add . && git rebase --continue
Emergency reset git reflog then git reset --hard HEAD@{n}

Your Next Steps 🚀

  1. Try it today - Pick your current feature and split it into 2-3 logical chunks
  2. Start small - Stack just 2 branches first
  3. Measure success - Track your review times before/after
  4. Spread the knowledge - Your teammates will love you for this

The bottom line: Stacked PRs aren't just a workflow—they're a superpower. Master this, and you'll never go back to monster PRs again.

Found this helpful? Drop a 🔥 in the comments and share with your team!

Top comments (0)