Rebase vs merge mental model in Git - Trade-offs & Expert Analysis

Overview - Rebase vs merge mental model

What is it?

Rebase and merge are two ways to combine changes from one branch into another in git, a tool that tracks code changes. Merge creates a new commit that joins the histories of both branches, keeping all commits intact. Rebase moves or rewrites commits from one branch onto another, creating a linear history. Both help integrate work but do it differently.

Why it matters

Without rebase or merge, developers would struggle to combine their work safely and clearly, leading to confusion and lost changes. These tools solve the problem of integrating parallel work streams, making collaboration smoother and history easier to understand. Choosing the right method affects how clean and understandable the project history is, which impacts debugging and teamwork.

Where it fits

Before learning this, you should understand basic git concepts like commits, branches, and how to create and switch branches. After mastering rebase and merge, you can learn advanced git workflows, conflict resolution, and tools like cherry-pick or interactive rebase.

Mental Model

Core Idea

Rebase rewrites history to create a straight line of changes, while merge combines histories preserving all branches as they happened.

Think of it like...

Imagine two friends writing a story together. Merge is like putting their separate story chapters side by side in a scrapbook, showing both paths clearly. Rebase is like rewriting one friend's chapters to fit directly after the other's, making it look like one continuous story.

Main branch: A---B---C
Feature branch:       D---E

Merge result:
A---B---C---M
          \     /
           D---E

Rebase result:
A---B---C---D'---E'

(M = merge commit, D' and E' are rebased commits)

Build-Up - 6 Steps

1

Foundation

Understanding git branches and commits

Concept: Learn what branches and commits are in git and how they represent work.

A commit is a snapshot of your code at a point in time. A branch is a pointer to a series of commits. When you create a branch, you start a new line of work separate from the main branch.

Result

You can create and switch branches to work on different features without affecting the main code.

Knowing branches and commits is essential because rebase and merge operate on these structures to combine work.

2

Foundation

Basic merge operation in git

Concept: Learn how git merge combines two branches by creating a new commit.

When you merge a feature branch into main, git creates a new commit called a merge commit. This commit has two parents, preserving the history of both branches.

Result

The main branch now includes all changes from the feature branch, and the history shows both branches clearly.

Understanding merge commits helps you see how git preserves the full history of parallel work.

3

Intermediate

What rebase does to commit history

🤔Before reading on: do you think rebase adds new commits or moves existing ones? Commit to your answer.

Concept: Rebase takes commits from one branch and re-applies them onto another branch, changing their base.

Instead of creating a merge commit, rebase rewrites the feature branch commits as if they were made after the main branch commits. This creates a linear history without branches.

Result

The feature branch appears as if it was developed from the latest main branch state, making history cleaner.

Knowing that rebase rewrites commits explains why it changes history and why it can simplify the project timeline.

4

Intermediate

Handling conflicts during merge and rebase

🤔Before reading on: do you think conflict resolution is the same for merge and rebase? Commit to your answer.

Concept: Both merge and rebase can cause conflicts when changes overlap, but the process differs slightly.

During merge, conflicts happen once when combining branches. During rebase, conflicts may occur at each commit being replayed. You must resolve conflicts and continue the process.

Result

You learn that rebase can require more conflict resolution steps but results in a cleaner history.

Understanding conflict handling differences helps choose the right tool for your workflow and prepare for the effort involved.

5

Advanced

Impact on collaboration and shared branches

🤔Before reading on: is it safe to rebase a branch others are using? Commit to your answer.

Concept: Rebasing changes commit history, which can cause problems if others share the branch.

If you rebase a branch that others have pulled, their history will differ, causing confusion and extra work to fix. Merge preserves history, so it's safer for shared branches.

Result

You understand why teams often avoid rebasing public branches and prefer merge in those cases.

Knowing when rebasing is safe prevents collaboration issues and lost work.

6

Expert

Rebase internals and commit rewriting

🤔Before reading on: do you think rebase changes commit IDs? Commit to your answer.

Concept: Rebase creates new commits with new IDs by replaying changes onto a new base commit.

Git applies each commit from the feature branch onto the target branch as a patch, creating new commits with new hashes. This is why rebasing rewrites history and changes commit IDs.

Result

You realize that rebasing is not just moving pointers but creating new commits, which affects history and collaboration.

Understanding commit rewriting explains why rebasing can be powerful but risky if misused.

Under the Hood

Git stores commits as snapshots linked by parent commit hashes. Merge creates a new commit with two parents, joining histories. Rebase detaches commits from their original base and reapplies them onto a new base, creating new commits with new hashes. This process involves applying patches and updating branch pointers.

Why designed this way?

Merge was designed to preserve complete history and show all branches explicitly, aiding traceability. Rebase was introduced to simplify history by linearizing commits, making it easier to follow changes. The tradeoff is between preserving history and having a clean, linear timeline.

Branch A: A---B---C
Branch B:       D---E

Merge:
A---B---C---M
          \     /
           D---E

Rebase:
A---B---C---D'---E'

Where M is merge commit, D' and E' are new commits created by rebase.

Myth Busters - 4 Common Misconceptions

Quick: Does rebasing delete your commits? Commit yes or no before reading on.

Common Belief: Rebasing deletes commits from your branch.

Reality: Rebasing does not delete commits but creates new commits with the same changes based on a new base.

Why it matters: Thinking rebasing deletes commits may cause fear of losing work and prevent using a powerful tool.

Quick: Is merging always better than rebasing for collaboration? Commit yes or no before reading on.

Common Belief: Merging is always safer and better for teamwork than rebasing.

Reality: Merging is safer for shared branches, but rebasing is better for cleaning up local commits before sharing.

Why it matters: Misunderstanding this leads to messy histories or collaboration conflicts.

Quick: Does a merge commit mean your history is messy? Commit yes or no before reading on.

Common Belief: Merge commits always clutter the git history and should be avoided.

Reality: Merge commits preserve the true history of parallel work and are useful for understanding how branches combined.

Why it matters: Avoiding merge commits blindly can hide important context about how features were integrated.

Quick: Can you safely rebase a branch that others have pulled? Commit yes or no before reading on.

Common Belief: You can rebase any branch at any time without issues.

Reality: Rebasing a branch others use rewrites history and causes conflicts for them.

Why it matters: Ignoring this causes confusion, duplicated commits, and wasted time fixing history.

Expert Zone

1

Rebasing preserves the patch content but changes commit hashes, which affects tools relying on commit IDs like CI pipelines or code reviews.

2

Merge commits can be squashed later to clean history, combining benefits of both approaches.

3

Interactive rebase allows selective editing, reordering, or combining commits, giving fine control over history.

When NOT to use

Avoid rebasing public or shared branches to prevent collaboration conflicts. Use merge instead for integrating shared work. For cleaning up local commits before sharing, rebase is preferred.

Production Patterns

Teams often use feature branches rebased onto main before merging to keep history linear. Merge commits are used to integrate completed features, preserving context. Interactive rebase is used to polish commits before code review.

Connections

Version Control Systems

Rebase and merge are specific operations within version control systems like git.

Understanding these operations deepens knowledge of how version control manages parallel work and history.

Conflict Resolution

Both rebase and merge require resolving conflicts when changes overlap.

Mastering conflict resolution improves the effectiveness of both rebase and merge workflows.

Storytelling and Narrative Structure

Rebase creates a linear narrative, while merge preserves multiple storylines.

Recognizing this helps appreciate how history presentation affects understanding and communication.

Common Pitfalls

#1 Rebasing a branch that others have already pulled.

Wrong approach:

git checkout feature
git rebase main
# Then push with git push origin feature

Correct approach:

git checkout feature
git merge main
# Then push with git push origin feature

Root cause:

Misunderstanding that rebasing rewrites history and causes conflicts for others sharing the branch.

#2 Ignoring conflicts during rebase and forcing continuation.

Wrong approach:

git rebase main
# Conflict occurs
git rebase --continue
# Without resolving conflicts properly

Correct approach:

git rebase main
# Conflict occurs
# Manually fix conflicts in files
git add
git rebase --continue

Root cause:

Not understanding that conflicts must be resolved before continuing rebase.

#3 Assuming merge commits always clutter history and deleting them blindly.

Wrong approach:

git merge --squash feature
git commit -m 'Squashed feature'

Correct approach:

git merge feature
# Keep merge commit to preserve history

Root cause:

Believing merge commits are always bad, ignoring their value in showing integration points.

Key Takeaways

Rebase rewrites commit history to create a clean, linear sequence of changes, while merge preserves the full branching history by creating a merge commit.

Choosing between rebase and merge depends on collaboration context: rebase is great for local cleanup, merge is safer for shared branches.

Rebasing changes commit IDs because it creates new commits, which can cause problems if others share the branch.

Merge commits provide valuable context about how branches combined and should not be avoided blindly.

Understanding conflict resolution differences between rebase and merge helps you manage integration smoothly.