When to rebase vs when to merge in Git - Visual Side-by-Side Comparison

Process Flow - When to rebase vs when to merge

Start: Branches diverge

↓

Choose action

↓

Rebase

↓

Linear history

↓

Clean history

↓

End: Updated branch

This flow shows the choice between rebasing and merging when branches diverge, leading to either a linear history with rebase or a merge commit preserving context.

Execution Sample

Git

git checkout feature
# Option 1: Rebase
 git rebase main

# Option 2: Merge
 git merge main

This code shows switching to a feature branch and then either rebasing it onto main or merging main into it.

Process Table

Step	Action	Branch State Before	Command	Branch State After	Resulting History
1	Start on feature branch diverged from main	feature and main have different commits	git checkout feature	On feature branch	Branches diverged
2	Rebase feature onto main	feature behind main	git rebase main	feature commits replayed on top of main	Linear history, no merge commit
3	Merge main into feature	feature behind main	git merge main	feature branch has merge commit	History shows merge commit preserving context
4	End	feature updated	none	feature updated with main changes	Either linear or merge commit history

💡 Execution stops after feature branch is updated either by rebase or merge.

Status Tracker

Variable	Start	After Step 2 (Rebase)	After Step 3 (Merge)
feature branch commits	A-B (diverged from main)	A-B replayed on top of main (linear)	A-B plus merge commit with main

Key Moments - 3 Insights

Why does rebase create a linear history?

Because rebase moves feature branch commits to the tip of main, replaying them as new commits, as shown in execution_table step 2.

Why does merge create a merge commit?

Merge combines histories preserving the original commits and adds a merge commit, as shown in execution_table step 3.

When should I prefer rebase over merge?

Prefer rebase for a clean, linear history when working alone or before sharing; prefer merge to preserve context when collaborating, as implied by the branch states in variable_tracker.

Visual Quiz - 3 Questions

Look at the execution_table, what is the resulting history after running 'git rebase main' on feature branch?

A Feature branch is deleted

B Linear history with no merge commit

C History with a merge commit

D Main branch is reset

💡 Hint

See execution_table row 2 under 'Resulting History'

At which step does the feature branch get a merge commit?

A Step 3

B Step 1

C Step 2

D Step 4

💡 Hint

Check execution_table row 3 under 'Branch State After'

If you want to keep a clean history without merge commits, which command should you use?

A git checkout main

B git merge main

C git rebase main

D git reset --hard

💡 Hint

Refer to variable_tracker and execution_table step 2 for linear history

Concept Snapshot

When branches diverge, use 'git rebase' to replay commits on main for a clean linear history.
Use 'git merge' to combine branches preserving all commits with a merge commit.
Rebase rewrites history; merge preserves it.
Rebase is good before sharing; merge is safer for collaboration.
Choose based on whether you want clean history or context preservation.

Full Transcript

When working with Git branches, you often need to update your feature branch with changes from the main branch. You can do this by either rebasing or merging. Rebasing moves your feature commits on top of the latest main branch commits, creating a straight, linear history without merge commits. Merging combines the histories and adds a merge commit, preserving the context of how branches came together. Use rebase when you want a clean history and are working alone or before sharing your branch. Use merge when collaborating to keep the full history intact. The execution table shows the step-by-step changes in branch state and history after each command.