Shows the decision flow when merging two branches using different strategies and their effects.
Execution Sample
Git
git checkout feature
# switch to feature branchgit merge main
# merge main into feature branch
Merges the main branch into the feature branch using the default merge strategy.
Process Table
Step
Action
Merge Strategy
Result
Branch State
1
Checkout feature branch
N/A
Switched to feature
HEAD at feature branch tip
2
Run 'git merge main'
Default (recursive)
Creates merge commit
feature branch updated with merge commit
3
Run 'git rebase main'
Rebase
Replays feature commits on main
feature branch commits rewritten on top of main
4
Run 'git merge --squash main'
Squash
Stages squashed changes
Working directory updated, no commit yet
5
Run 'git merge --ff-only main'
Fast-forward
Moves branch pointer if possible
feature branch pointer moved forward
6
Exit
N/A
Merge complete or aborted
Branches merged or no changes
💡 Merge finishes when commits are combined or branch pointers updated, or aborted if conflicts unresolved.
Status Tracker
Variable
Start
After Step 2
After Step 3
After Step 4
After Step 5
Final
feature_branch
commit F1
commit MC (merge commit)
commit F1' (rebased)
working tree with combined changes
commit M (fast-forwarded)
merged state
main_branch
commit M
commit M
commit M
commit M
commit M
commit M
Key Moments - 3 Insights
Why does 'git merge --rebase' rewrite commits instead of creating a merge commit?
Because rebase moves feature branch commits on top of main, replaying them to create a linear history, as shown in step 3 of the execution_table.
What happens if 'git merge --ff-only' cannot fast-forward?
The merge aborts without changes because fast-forward requires the current branch to be behind the target branch, as implied in step 5 where pointer moves only if possible.
Why does 'git merge --squash' not create a commit immediately?
Squash combines all changes into the working directory but waits for user to commit manually, shown in step 4 where working tree updates but no commit is made.
Visual Quiz - 3 Questions
Test your understanding
Look at the execution_table, what is the branch state after running 'git merge --rebase main'?
Afeature branch pointer moved forward
BWorking directory updated, no commit yet
Cfeature branch commits rewritten on top of main
DCreates merge commit
💡 Hint
Check row 3 under 'Branch State' in execution_table.
At which step does the merge create a merge commit?
AStep 4
BStep 2
CStep 3
DStep 5
💡 Hint
Look at the 'Result' column in execution_table for step 2.
If the feature branch is already ahead of main, what will 'git merge --ff-only main' do?
AAbort merge with no changes
BMove branch pointer forward
CCreate a merge commit
DCombine commits into one
💡 Hint
Refer to the explanation in key_moments about fast-forward behavior.
Concept Snapshot
Git merge strategies:
- Default merge: creates a merge commit combining histories.
- Rebase: replays commits on top of target branch for linear history.
- Squash: combines commits into one, requires manual commit.
- Fast-forward: moves branch pointer if no divergence.
Choose based on desired history style and conflict handling.
Full Transcript
This visual execution shows how Git merges two branches using different strategies. First, you start with two branches that have diverged. You choose a merge strategy: default merge creates a merge commit combining both histories; rebase replays your commits on top of the target branch for a linear history; squash combines all commits into one but waits for you to commit manually; fast-forward moves the branch pointer forward if possible without creating a merge commit. The execution table traces each step, showing branch states and results. Key moments clarify common confusions like why rebase rewrites commits or when fast-forward fails. The quiz tests understanding by referencing these steps. This helps beginners see how Git changes branch states with each merge strategy.