Git Merge vs Rebase — When to Use Each

In this tutorial, you'll learn about Git Merge vs Rebase. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

What You'll Learn

Understand the difference between Git merge and rebase — when each is appropriate, how they affect history, and how to use rebase without causing problems.

Why It Matters

Merge and rebase are the two ways to integrate changes. Using the wrong one creates messy history or broken collaboration. Knowing the difference separates beginner from pro.

Real-World Use

Merging a feature branch back to main (public), or rebasing a local branch to keep history clean before sharing.

The Core Difference

Merge: "I combined two streams of work"
History shows a merge commit with two parents.

Rebase: "I moved my work to start from a newer base"
History is linear — no merge commits.

Git Merge

git checkout feature
git merge main

    A---B---C feature
   /
D---E---F---G main
         ↓ git merge
    A---B---C feature
   /         \
D---E---F---G---H main (merge commit)

When to merge:

• Merging a feature branch back into main (public branch)
• When you want to preserve the exact timeline
• When the branch is shared with others
• When you want an explicit record of "when this feature was integrated"

Git Rebase

git checkout feature
git rebase main

    A---B---C feature
   /
D---E---F---G main
         ↓ git rebase
             A'---B'---C' feature
            /
D---E---F---G main

Rebase rewrites commits (A', B', C' are new commits) — they have different hashes.

When to rebase:

• Updating a local feature branch with latest main
• Before opening a Pull Request (clean history)
• When you want a linear, easy-to-follow history
• For local branch cleanup (interactive rebase)

The Golden Rule

Never rebase commits that have been pushed to a shared branch.

If you rebase a branch others are working on, their local history diverges from the remote — and they'll have painful merge conflicts.

Interactive Rebase

git rebase -i HEAD~3

# Opens an editor:
pick a1b2c3 First commit
pick d4e5f6 Second commit
pick g7h8i9 Third commit

# Available actions:
# pick   = use commit
# squash = combine with previous commit
# reword = change commit message
# edit   = stop to amend
# drop   = remove commit

Use cases:

• Squash fixup commits before PR
• Reword unclear messages
• Remove commits that shouldn't exist

Merge vs Rebase: Quick Reference

Practical Example

# Start a feature
git checkout -b add-payments

# Work while others push to main
echo "payment code" > payments.py
git add . && git commit -m "Add payment processing"

# Main has advanced
git checkout main
git pull
git checkout add-payments

# Option A: Merge (creates merge commit)
git merge main

# Option B: Rebase (linear history)
git rebase main

# After PR is approved, merge to main
git checkout main
git merge add-payments  # Not rebase — main is shared

Safety Net

# If rebase goes wrong:
git rebase --abort

# Or find your original commits:
git reflog
# Then reset back:
git reset --hard HEAD@{5}

Practice

1. Create a branch, make 3 commits
2. Rebase onto main (or any updated branch)
3. Use interactive rebase to squash the 3 commits into 1
4. Merge the branch to main