Merge strategies overview in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Git Merge Strategies

Which Git merge strategy creates a new commit when fast-forward is not possible?

A ours

B resolve

C octopus

D recursive

💡 Hint

Think about the default strategy Git uses for two-parent merges that preserves history.

The recursive strategy is the default for merging two branches and creates a merge commit when a fast-forward is not possible. Other strategies behave differently.

💻 Command Output

intermediate

Output of a Fast-Forward Merge

What is the output of the following Git command sequence?

git checkout main
git merge feature-branch

Assuming main is behind feature-branch and no conflicts exist.

A

Updating abc123..def456
Fast-forward

B Merge made by recursive.

C Automatic merge failed; fix conflicts and then commit the result.

D Already up to date.

💡 Hint

Consider what happens when the current branch can be moved forward without creating a merge commit.

A fast-forward merge moves the branch pointer forward without a merge commit, showing 'Fast-forward' in the output.

❓ Configuration

advanced

Configuring Git to Always Use the 'Ours' Merge Strategy

Which Git configuration command sets the default merge strategy to ours for all merges?

A git config --global merge.default ours

B git config --global merge.default-strategy ours

C git config --global merge.strategy ours

D git config --global merge.strategy.default ours

💡 Hint

Look for the correct Git config key for setting the merge strategy.

The correct key to set the default merge strategy is merge.strategy. Setting it to ours makes Git use that strategy by default.

❓ Troubleshoot

advanced

Troubleshooting a Failed Octopus Merge

You attempt to merge three branches at once using the octopus strategy but get an error. What is the most likely cause?

A There are conflicts between at least two branches.

B The octopus strategy only supports merging two branches.

C The branches have diverged too much for any merge.

D The repository is in a detached HEAD state.

💡 Hint

Octopus merges multiple branches but has limitations.

The octopus strategy can merge multiple branches but fails if there are conflicts. It does not handle conflicts well.

🔀 Workflow

expert

Choosing the Correct Merge Strategy for a Complex Workflow

You have a long-running feature branch and want to keep its history linear on the main branch but still incorporate upstream changes regularly. Which Git merge strategy and workflow combination best fits this need?

A Use 'git merge -s ours' to ignore upstream changes and keep feature branch history.

B Use 'git rebase' on the feature branch regularly before merging with fast-forward.

C Use 'git merge --no-ff' to create merge commits preserving history.

D Use 'git merge --squash' to combine all changes into one commit on main.

💡 Hint

Think about keeping a clean, linear history while incorporating upstream changes.

Rebasing the feature branch onto main regularly keeps history linear and up to date. Then merging with fast-forward avoids extra merge commits.

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