When to rebase vs when to merge in Git - Practice Questions

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Rebase vs Merge Purpose

Which statement best describes when you should use git rebase instead of git merge?

A Use rebase to permanently delete commits from the repository history.

B Use rebase to combine multiple commits into one without changing the commit history.

C Use rebase to create a new branch from an existing branch without merging changes.

D Use rebase to keep a clean, linear history by moving your changes on top of the latest main branch commits.

💡 Hint

Think about how rebase changes the commit history compared to merge.

Rebase moves your branch commits on top of the latest commits from another branch, creating a linear history. This is useful to keep history clean before merging.

🧠 Conceptual

intermediate

When to Prefer Merge Over Rebase

In which situation is it better to use git merge instead of git rebase?

A When you want to preserve the exact history of how branches diverged and merged, showing all merge commits.

B When you want to rewrite commit messages before integrating changes.

C When you want to delete a branch after integrating its changes.

D When you want to squash all commits into one before merging.

💡 Hint

Consider which method keeps the full branching history visible.

Merge preserves the full history including all branch points and merge commits, which is useful for understanding how development progressed.

🔀 Workflow

advanced

Choosing Rebase or Merge in a Team Workflow

Your team uses a shared main branch. You have a feature branch that you want to update with the latest main changes before merging. Which command sequence correctly updates your feature branch using rebase?

Git

git checkout feature
<cursor>

A git fetch origin && git merge origin/main

B git merge main

C git rebase main

D git pull origin main

💡 Hint

Rebase moves your commits on top of the latest main branch commits.

Running git rebase main while on your feature branch reapplies your commits on top of the current main branch, updating your branch cleanly.

❓ Troubleshoot

advanced

Resolving Conflicts During Rebase vs Merge

You ran git rebase main on your feature branch and encountered conflicts. After fixing conflicts, which command should you run to continue the rebase?

A git rebase --continue

B git merge --continue

C git commit -m 'fix conflicts'

D git rebase --abort

💡 Hint

Think about the command to resume a rebase after conflict resolution.

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

✅ Best Practice

expert

Best Practice for Public Branches

Which practice is recommended when working with branches shared publicly by others?

A Always rebase public branches to keep history clean.

B Avoid rebasing public branches to prevent rewriting shared history.

C Delete public branches frequently to reduce clutter.

D Force push after rebasing public branches to update everyone.

💡 Hint

Consider the impact of rewriting history on others who use the branch.

Rebasing rewrites commit history. Doing this on public branches can confuse collaborators and cause problems. It's safer to merge public branches.

Practice

1. What is the main reason to use git rebase instead of git merge?

easy

A. To delete the feature branch after merging

B. To keep all branch merge points visible in history

C. To create a clean, linear history without merge commits

D. To automatically resolve all conflicts

Solution

1. Step 1: Understand rebase purpose

   Rebase moves commits to create a straight line history without merge commits.

2. Step 2: Compare with merge

   Merge keeps all branch points and creates merge commits, showing full history.

3. Final Answer:

   To create a clean, linear history without merge commits -> Option C

4. Quick Check:

   Rebase = linear history [OK]

Hint: Rebase = linear history, Merge = full branch history [OK]

Common Mistakes:

• Thinking merge creates linear history
• Believing rebase deletes branches
• Assuming rebase auto-resolves conflicts

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

easy

A. git rebase origin/main

B. git merge main

C. git checkout main && git rebase

D. git rebase main

Solution

1. Step 1: Identify rebase command

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

2. Step 2: Check other options

   git merge main merges, not rebases; git checkout main && git rebase is incomplete; git rebase origin/main rebases onto remote branch, not local main.

3. Final Answer:

   git rebase main -> Option D

4. Quick Check:

   Rebase syntax = git rebase branch [OK]

Hint: Rebase current branch onto main: git rebase main [OK]

Common Mistakes:

• Confusing merge and rebase commands
• Using incomplete rebase syntax
• Rebasing onto remote branch unintentionally

3. You have a feature branch with 3 commits diverged from main. After running git rebase main, what will the commit history look like?

medium

A. The 3 commits will be replayed on top of the latest main commits

B. The 3 commits will be merged into a single commit on main

C. The 3 commits will be deleted and replaced by main commits

D. The 3 commits will remain unchanged and main will be merged

Solution

1. Step 1: Understand rebase effect on commits

   Rebase takes your commits and re-applies them on top of the target branch, here main.

2. Step 2: Compare with merge behavior

   Merge combines histories with a merge commit; rebase rewrites history to appear linear.

3. Final Answer:

   The 3 commits will be replayed on top of the latest main commits -> Option A

4. Quick Check:

   Rebase = replay commits on new base [OK]

Hint: Rebase replays commits on top of target branch [OK]

Common Mistakes:

• Thinking rebase merges commits
• Assuming commits are deleted
• Confusing merge and rebase results

4. You tried to rebase your branch onto main but got conflicts. What is the correct way to continue after resolving conflicts?

medium

A. Run git rebase --continue after fixing conflicts

B. Run git merge --continue after fixing conflicts

C. Run git commit to finish the rebase

D. Run git rebase --abort to keep the changes

Solution

1. Step 1: Identify rebase conflict resolution

   After fixing conflicts during rebase, you must run git rebase --continue to proceed.

2. Step 2: Check other options

   git merge --continue is for merge conflicts; git commit alone doesn't continue rebase; git rebase --abort cancels rebase.

3. Final Answer:

   Run git rebase --continue after fixing conflicts -> Option A

4. Quick Check:

   Fix conflicts + git rebase --continue [OK]

Hint: After conflict fix in rebase, run git rebase --continue [OK]

Common Mistakes:

• Using git merge --continue during rebase
• Running git commit instead of rebase continue
• Aborting rebase instead of continuing

5. Your team wants to keep a clear record of all branch merges for auditing, but also wants to avoid complex conflict resolution during integration. Which strategy should you choose?

hard

A. Use git rebase to keep history linear and avoid merge commits

B. Use git merge to preserve branch history and avoid rewriting commits

C. Use git rebase and then merge to keep both histories

D. Use git cherry-pick to manually apply commits

Solution

1. Step 1: Understand audit needs

   Keeping a clear record means preserving all branch merge points and history.

2. Step 2: Compare merge and rebase for conflicts

   Merge preserves history and avoids rewriting commits, reducing conflict complexity; rebase rewrites history and can cause conflicts.

3. Final Answer:

   Use git merge to preserve branch history and avoid rewriting commits -> Option B

4. Quick Check:

   Audit needs = merge to keep history [OK]

Hint: Preserve history and audit: choose git merge [OK]

Common Mistakes:

• Choosing rebase when audit needs full history
• Mixing rebase and merge without clear purpose
• Using cherry-pick for full branch integration