Merge strategies overview in Git - Step-by-Step Execution

Process Flow - Merge strategies overview

Start: Two branches diverged

↓

Choose merge strategy

↓

Merge

↓

Create merge commit

↓

Replay commits

↓

Combine commits

↓

Move branch pointer

↓

Branches merged

Shows the decision flow when merging two branches using different strategies and their effects.

Execution Sample

Git

git checkout feature
# switch to feature branch

git 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

Look at the execution_table, what is the branch state after running 'git merge --rebase main'?

A feature branch pointer moved forward

B Working directory updated, no commit yet

C feature branch commits rewritten on top of main

D Creates merge commit

💡 Hint

Check row 3 under 'Branch State' in execution_table.

At which step does the merge create a merge commit?

A Step 4

B Step 2

C Step 3

D Step 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?

A Abort merge with no changes

B Move branch pointer forward

C Create a merge commit

D Combine 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.

Practice

1. What does the --no-ff option do when merging branches in Git?

easy

A. It creates a merge commit even if a fast-forward merge is possible.

B. It squashes all commits into one before merging.

C. It deletes the source branch after merging.

D. It aborts the merge if conflicts are found.

Solution

1. Step 1: Understand fast-forward merges

   A fast-forward merge moves the branch pointer forward without creating a new commit if no divergent changes exist.

2. Step 2: Effect of --no-ff

   The --no-ff option forces Git to create a merge commit even if a fast-forward is possible, preserving branch history.

3. Final Answer:

   It creates a merge commit even if a fast-forward merge is possible. -> Option A

4. Quick Check:

   --no-ff keeps history with merge commit [OK]

Hint: Remember: --no-ff always makes a merge commit [OK]

Common Mistakes:

• Confusing --no-ff with --squash
• Thinking it deletes branches
• Assuming it aborts on conflicts

2. Which of the following is the correct syntax to perform a squash merge of branch feature into main?

easy

A. git merge --squash feature

B. git merge feature --no-ff

C. git merge --fast-forward feature

D. git merge --abort feature

Solution

1. Step 1: Identify squash merge syntax

   The --squash option is used with git merge to combine all commits from the source branch into one commit on the target branch.

2. Step 2: Check command correctness

   git merge --squash feature is the correct syntax to squash merge the feature branch into the current branch.

3. Final Answer:

   git merge --squash feature -> Option A

4. Quick Check:

   Squash merge syntax = git merge --squash [OK]

Hint: Use --squash right after git merge for squash merges [OK]

Common Mistakes:

• Placing --no-ff instead of --squash
• Using --abort which cancels merges
• Assuming --fast-forward is a valid option

3. Given the following commands run on branch main:

git merge feature

If feature has 3 commits and no conflicts, what will be the result in the commit history?

medium

A. A single new merge commit combining all changes from feature.

B. Merge aborted due to conflicts.

C. Three separate commits from feature added to main with no merge commit.

D. No new commits; main pointer moves forward (fast-forward).

Solution

1. Step 1: Understand default merge behavior

   By default, if the main branch has no new commits since branching, Git performs a fast-forward merge, moving the main pointer forward.

2. Step 2: Analyze the scenario

   Since feature has 3 commits and main has no new commits, Git will fast-forward main to feature's tip without creating a merge commit.

3. Final Answer:

   No new commits; main pointer moves forward (fast-forward). -> Option D

4. Quick Check:

   Default merge with no divergence = fast-forward [OK]

Hint: If no new commits on main, merge fast-forwards [OK]

Common Mistakes:

• Assuming a merge commit is always created
• Thinking commits are duplicated
• Confusing conflicts with no conflicts

4. You tried to merge branch feature into main using git merge feature, but Git reports conflicts. What is the best way to resolve this?

medium

A. Delete the feature branch and start over.

B. Run git merge --abort to cancel the merge and lose changes.

C. Manually edit conflicting files, then run git add and git commit.

D. Use git reset --hard to force merge.

Solution

1. Step 1: Understand merge conflicts

   Conflicts occur when Git cannot automatically combine changes. Manual intervention is needed to fix conflicting files.

2. Step 2: Resolve conflicts properly

   Edit the conflicting files to fix issues, then stage changes with git add and complete the merge with git commit.

3. Final Answer:

   Manually edit conflicting files, then run git add and git commit. -> Option C

4. Quick Check:

   Resolve conflicts manually, then add and commit [OK]

Hint: Fix conflicts manually, then add and commit [OK]

Common Mistakes:

• Aborting merge loses progress
• Deleting branches unnecessarily
• Using reset which discards changes

5. You want to merge a long-lived feature branch into main but keep the commit history clean with a single commit representing all changes. Which merge strategy should you use and what is the correct sequence?

hard

A. Use git merge --no-ff feature to keep all commits and a merge commit.

B. Use git merge --squash feature then commit manually.

C. Use git rebase main feature then fast-forward merge.

D. Delete feature and copy files manually.

Solution

1. Step 1: Identify goal - single commit for all changes

   Squash merge combines all commits from the feature branch into one commit on main, keeping history clean.

2. Step 2: Correct merge sequence

   Run git merge --squash feature to prepare changes, then create a new commit manually with git commit.

3. Final Answer:

   Use git merge --squash feature then commit manually. -> Option B

4. Quick Check:

   Squash merge + manual commit = single clean commit [OK]

Hint: Squash merge then commit for one clean commit [OK]

Common Mistakes:

• Using --no-ff which keeps all commits
• Confusing rebase with squash merge
• Deleting branches instead of merging