Git Rebase vs Merge: When to Use Which (2026 Edition)

import Post from ’../../layouts/Post.astro’; export const prerender = true;

The merge vs rebase debate has caused more wasted arguments thanTabs vs Spaces. Here’s the rule set I actually follow in production, learned from years of getting it wrong.

The Core Mental Model

Merge = preserves history, creates a merge commit, diverges then reconverges.

Rebase = rewrites history to look like sequential development, no merge commit.

# Merge: history looks like what actually happened
#       A---B---C  feature
#      /         \
# D---E---F---G---H  main (merge commit H)

git checkout feature && git merge main

# Rebase: history looks like you started from latest main
# A---B---C  feature (rewritten)
#          \
# D---E---F---G  main

git checkout feature && git rebase main

When to Rebase

1. Feature branches that are private

# You alone are working on this branch
# It's never been pushed to shared remote
git checkout -b feature/user-auth
# ... commit a few times ...
# Oops, main moved. Rebase to get latest:
git rebase main
# Now your commits apply cleanly on top of main

Rebase is safe here because nobody else has your commits. You’re the only one who could be confused by the rewritten history.

2. Keeping feature branches up to date

# Instead of:
git checkout feature
git merge main  # messy merge commit in your branch history

# Do this:
git rebase main  # clean linear history

When you’re done and merge with a PR, the PR shows only your commits — not 12 “merge main into feature” commits.

3. Cleaning up commits before PR

# Interactive rebase to squash, reorder, edit commits
git rebase -i HEAD~5

# In the editor:
pick abc1234 Add user authentication
pick def5678 WIP
pick ghi9012 WIP more
pick jkl3456 Final complete auth

# Change to:
pick abc1234 Add user authentication
squash def5678 WIP
squash ghi9012 WIP more
squash jkl3456 Final complete auth

Result: one clean commit for the PR. git log stays readable.

When to MERGE (Not Rebase)

1. Shared branches that multiple people work on

# NEVER rebase a branch that:
# - Has been pushed to shared remote
# - Multiple developers have pulled from
# - Is being code-reviewed via PR

git rebase main  # BAD if shared
git push --force-with-lease  # YOUR PROBLEM NOW

Someone else pulled your branch? Rebasing breaks their local history. Force push causes chaos.

2. Release branches

Release branches are frozen. Merge main into release/1.0 never rebased.

3. Long-lived feature branches

If a feature takes 3 weeks and main moves constantly:

# Instead of rebasing every day (creates messy graph):
git merge main  # Merge commit shows when you synced

# OR: merge main INTO feature, then rebase feature ONTO main at PR time

The Rule I Actually Follow

Situation	Action
Private branch, rebasing	Rebase away
PR being reviewed	Don’t rebase — let reviewers see real diff
Branch has been pushed to shared remote	Merge only
Need to sync with main	Merge (safer, no history rewriting)
Cleaning commits before PR	Interactive rebase (-i) — safe before push
After PR approval	Fast-forward merge or squash-merge

My Actual Workflow

# 1. Create feature branch from latest main
git checkout main && git pull
git checkout -b feature/my-feature

# 2. Work, commit. To sync with main without rebasing:
git merge main  # or cherry-pick specific commits

# 3. Before PR: cleanup history (only if private branch)
git rebase -i HEAD~5  # squash WIP commits

# 4. Merge PR via GitHub/GitLab UI:
#    - Squash and merge (one commit per feature)
#    - OR regular merge (preserve all commits)

TL;DR: Rebase is for making your personal commit history clean. Merge is for combining work from multiple people. Use the right tool for each situation — most of the time merge is safer.