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.

Practice

1. What is the main difference between git merge and git rebase?

easy

A. git merge rewrites commit messages; git rebase preserves commit messages.

B. git merge deletes the source branch; git rebase deletes the target branch.

C. git merge only works on remote branches; git rebase only works on local branches.

D. git merge combines histories preserving all commits; git rebase rewrites history to create a linear sequence.

Solution

1. Step 1: Understand git merge behavior

   git merge combines two branches by creating a new commit that preserves the history of both branches without changing existing commits.

2. Step 2: Understand git rebase behavior

   git rebase moves or reapplies commits from one branch onto another, rewriting history to make it look like a straight line.

3. Final Answer:

   git merge combines histories preserving all commits; git rebase rewrites history to create a linear sequence. -> Option D

4. Quick Check:

   Merge preserves history, rebase rewrites it [OK]

Hint: Merge keeps history; rebase rewrites it linearly [OK]

Common Mistakes:

• Thinking merge deletes branches
• Believing rebase only works on remote branches
• Confusing which command rewrites history

2. Which of the following is the correct syntax to rebase the current branch onto main?

easy

A. git rebase main

B. git merge main

C. git rebase origin/main

D. git checkout main && git rebase

Solution

1. Step 1: Identify the command to rebase current branch

   The command git rebase main rebases the current branch onto the main branch.

2. Step 2: Check other options for correctness

   git merge main merges, not rebases; git rebase origin/main rebases onto remote tracking branch which may be outdated; git checkout main && git rebase is invalid syntax.

3. Final Answer:

   git rebase main -> Option A

4. Quick Check:

   Rebase current branch onto main = git rebase main [OK]

Hint: Use 'git rebase branch-name' to rebase current branch [OK]

Common Mistakes:

• Using merge instead of rebase
• Rebasing onto remote branch without fetching
• Incorrect chaining of commands

3. Given the following commands executed in order on branch feature:

git checkout feature
git rebase main
git log --oneline --graph

What will the commit history look like compared to using git merge main instead?

medium

A. A linear history with feature commits on top of main commits.

B. A merge commit combining main and feature histories.

C. No change in history; feature branch remains separate.

D. Feature branch commits are deleted.

Solution

1. Step 1: Understand effect of git rebase main on feature branch

   Rebasing moves feature commits to be based on the latest main commits, creating a straight, linear history.

2. Step 2: Compare with git merge main effect

   Merging creates a new merge commit that combines histories, preserving the branch structure and showing a branch point.

3. Final Answer:

   A linear history with feature commits on top of main commits. -> Option A

4. Quick Check:

   Rebase = linear history; merge = merge commit [OK]

Hint: Rebase = linear history; merge = merge commit [OK]

Common Mistakes:

• Thinking rebase creates merge commits
• Believing history stays unchanged after rebase
• Assuming commits are deleted after rebase

4. You ran git rebase main on your feature branch but got conflicts. After resolving conflicts, which command should you run to continue the rebase?

medium

A. git commit -m 'resolved conflicts'

B. git merge --continue

C. git rebase --continue

D. git rebase --abort

Solution

1. Step 1: Identify the correct command to continue rebase after conflicts

   After resolving conflicts during a rebase, git rebase --continue tells Git to proceed with applying remaining commits.

2. Step 2: Understand other options

   git merge --continue is for merge conflicts, not rebase; git commit -m is manual commit but rebase expects --continue; git rebase --abort cancels the rebase.

3. Final Answer:

   git rebase --continue -> Option C

4. Quick Check:

   Continue rebase after conflicts = git rebase --continue [OK]

Hint: Use 'git rebase --continue' after resolving conflicts [OK]

Common Mistakes:

• Using merge commands during rebase
• Trying to commit manually instead of continuing
• Aborting instead of continuing rebase

5. You want to update your feature branch with the latest changes from main but keep a clean, linear history without merge commits. Which sequence of commands achieves this safely?

hard

A. git checkout feature; git merge origin/main

B. git checkout feature; git fetch origin; git rebase origin/main

C. git checkout main; git pull; git checkout feature; git merge main

D. git checkout feature; git pull origin main

Solution

1. Step 1: Fetch latest changes from remote main branch

   git fetch origin updates local remote tracking branches without changing working branches.

2. Step 2: Rebase feature branch onto updated origin/main

   git rebase origin/main reapplies feature commits on top of latest main commits, keeping history linear and clean.

3. Final Answer:

   git checkout feature; git fetch origin; git rebase origin/main -> Option B

4. Quick Check:

   Fetch then rebase for clean update [OK]

Hint: Fetch first, then rebase onto remote main for clean history [OK]

Common Mistakes:

• Merging instead of rebasing for linear history
• Pulling directly on feature branch causing merge commits
• Not fetching latest remote changes before rebase