15+ Git Rebase vs Merge Interview Questions 2025: Workflows, Conflicts & Recovery

The Linux kernel project—with over 27 million lines of code and thousands of contributors—uses rebasing extensively. Meanwhile, many enterprise teams forbid it entirely. The rebase vs merge question reveals whether you understand distributed version control deeply and whether you've learned the "golden rule" that prevents catastrophic history rewrites.

Table of Contents

1. Git Merge vs Rebase Fundamentals Questions
2. Commit Graph and History Questions
3. The Golden Rule Questions
4. Interactive Rebase Questions
5. Conflict Resolution Questions
6. Recovery and Undo Questions
7. Workflow Questions
8. Quick Reference

Git Merge vs Rebase Fundamentals Questions

These questions test your understanding of the core difference between merge and rebase.

What is the difference between git merge and git rebase?

Merge combines two branches by creating a new commit with two parents, preserving the complete history of both branches. Rebase takes your commits and replays them onto another branch, creating new commits with new hashes and resulting in a linear history.

Think of merge like recording a jam session—when you merge two branches, Git creates a new commit that says "these two musical tracks were combined here." Both original tracks are preserved exactly as they were recorded, and the merge commit documents the exact moment they came together. You can always go back and see exactly what each branch looked like before the merge. This is why merge is considered "non-destructive"—it doesn't change any existing commits.

Rebase, on the other hand, is like re-recording your parts over a new backing track. When you rebase your feature branch onto main, Git takes each of your commits and replays them one by one on top of the latest main. The result looks like you wrote all your code after everyone else's changes, even if you actually started weeks ago. The original commits are effectively replaced with new ones that have different parent commits and therefore different SHA hashes.

When should you use git rebase vs merge?

The choice depends on whether you're working with shared or local branches and what kind of history you want to maintain.

Use merge when working on shared/public branches, when you want to preserve complete history, or when merging feature branches into main. Use rebase when updating a local feature branch with changes from main, when cleaning up commits before a pull request, or when you want a linear history.

A pattern that works well is using rebase to keep your local feature branch updated with main while you're developing, but using merge when integrating your completed feature into the shared main branch. This gives you the clean history benefits of rebase during development while avoiding the dangers of rewriting shared history.

Key principle: Rebase for updating local branches, merge for integrating into shared branches.

Commit Graph and History Questions

These questions test your understanding of how Git's commit graph changes with each operation.

How does the commit graph change with merge vs rebase?

Understanding the visual difference is crucial. Imagine you have a main branch with three commits (A, B, C), and you created a feature branch from commit B with two commits (D, E):

main:     A---B---C
               \
feature:        D---E

When you merge the feature branch into main, Git creates a new merge commit (M) that has two parents:

main:     A---B---C-------M
               \         /
feature:        D---E---/

The merge commit M is like a knot tying two threads together. Both threads are preserved exactly as they were.

When you rebase feature onto main instead, Git identifies commits D and E, temporarily sets them aside, moves the feature branch pointer to C, and replays D and E on top:

main:     A---B---C
                   \
feature:            D'---E'

Notice D' and E' instead of D and E—these are new commits with different SHA hashes, even though they contain the same code changes. After rebasing, merging feature into main can be a "fast-forward" merge:

main:     A---B---C---D'---E'

This linear history is easier to read and understand.

What is a fast-forward merge?

A fast-forward merge occurs when the target branch (like main) hasn't diverged from the source branch. Instead of creating a merge commit, Git simply moves the branch pointer forward.

This happens naturally after rebasing because your feature branch is directly ahead of main. Git can "fast-forward" the main pointer to the tip of your feature branch without creating a merge commit.

# After rebasing feature onto main
git checkout main
git merge feature  # Fast-forward, no merge commit created

If you want to always create a merge commit even when fast-forward is possible (to preserve the record that a feature branch existed), use:

git merge --no-ff feature

The Golden Rule Questions

These questions test your understanding of when rebasing becomes dangerous.

What is the golden rule of rebasing?

Never rebase commits that have been pushed to a public or shared repository where others might have based work on them.

Because rebase creates new commits with new hashes, anyone who based work on your original commits now has a problem. Their work references commits that no longer exist in the same form.

Consider this scenario: you're working on a feature branch and push it so your teammate can collaborate:

Your feature:  A---B---C  (pushed to origin)
                       \
Teammate's:             D---E

Now you rebase your feature branch onto main:

Your feature:  A---B'---C'  (rebased, new commits!)

Teammate's:    D---E  (still points to original C, which "no longer exists")

Your teammate's commits D and E are now based on commit C that has effectively been replaced by C'. When they try to push or you try to integrate their work, Git sees completely divergent histories, resulting in duplicate commits and confusing merge conflicts.

How do you safely force push after rebasing?

If you must push after rebasing a branch that only you work on, use --force-with-lease instead of --force:

git push --force-with-lease

The --force-with-lease flag checks that the remote branch is where you expect it to be, refusing to push if someone else has added commits since you last fetched. This prevents accidentally overwriting a teammate's work.

Regular --force is dangerous because it overwrites the remote branch unconditionally. With --force-with-lease, Git verifies no new commits exist on the remote before allowing the push.

Interactive Rebase Questions

These questions test your ability to clean up commit history.

What is interactive rebase and how do you use it?

Interactive rebase (git rebase -i) lets you modify commits during the rebase process. You can squash multiple commits into one, reword commit messages, reorder commits, edit commit contents, or drop commits entirely.

Say your commit history looks like this:

abc123 Add login form
def456 Fix typo in login form
ghi789 Add validation to login form
jkl012 Fix validation bug
mno345 Add password strength indicator
pqr678 Fix password strength indicator styling

Run git rebase -i HEAD~6 to interactively rebase the last 6 commits. Git opens your editor:

pick abc123 Add login form
pick def456 Fix typo in login form
pick ghi789 Add validation to login form
pick jkl012 Fix validation bug
pick mno345 Add password strength indicator
pick pqr678 Fix password strength indicator styling

Edit to squash related commits:

pick abc123 Add login form
squash def456 Fix typo in login form
squash ghi789 Add validation to login form
squash jkl012 Fix validation bug
pick mno345 Add password strength indicator
squash pqr678 Fix password strength indicator styling

The result is a clean, logical history:

abc123 Add login form with validation
def456 Add password strength indicator

What are the interactive rebase commands?

The available commands give you powerful control over commit history:

A useful workflow: when you make a small fix to a previous commit, run git commit --fixup=abc123 where abc123 is the commit you're fixing. This creates a commit labeled "fixup! Add login form". Later, git rebase -i --autosquash HEAD~5 automatically reorders and marks fixup commits for squashing.

How do you fix a typo in a commit message from 3 commits ago?

Use interactive rebase with the reword command:

git rebase -i HEAD~3

In the editor, change pick to reword for the commit with the typo:

reword abc123 Add login form  # Will prompt to edit message
pick def456 Add validation
pick ghi789 Add tests

When you save and close, Git opens another editor where you can fix the commit message. This creates new commits with corrected messages (and new hashes) for that commit and all subsequent commits.

Conflict Resolution Questions

These questions test your understanding of how conflicts differ between merge and rebase.

How do you resolve conflicts during merge vs rebase?

With merge, you resolve all conflicts at once. Git tries to combine the two branch tips, finds all places where automatic merging fails, marks them all as conflicted, and waits for you to resolve everything before creating the merge commit.

With rebase, conflicts are handled commit-by-commit. Git replays each of your commits onto the target branch one at a time. If the first commit causes a conflict, you resolve it and continue. If the third commit also causes a conflict, you resolve that too. This means you might resolve the same conflict multiple times if several commits touched the same lines.

Rebase conflict workflow:

# Start the rebase
git rebase main
 
# Git stops at the first conflicting commit
# CONFLICT (content): Merge conflict in src/auth.js
 
# Open the file and resolve the conflict markers
<<<<<<< HEAD
const AUTH_URL = '/api/v2/auth';
=======
const AUTH_URL = '/api/v1/auth';
>>>>>>> feat: Add login form
 
# Edit to resolve, then stage
git add src/auth.js
 
# Continue to the next commit
git rebase --continue
 
# Repeat until all commits are replayed

How do you abort a rebase in progress?

If things go badly wrong during a rebase, abort and return to your pre-rebase state:

git rebase --abort

This restores your branch to exactly where it was before you started the rebase. All your original commits are intact.

You can also skip a problematic commit if you decide you don't need it:

git rebase --skip

Recovery and Undo Questions

These questions test your ability to recover from Git mistakes.

How do you undo a rebase if something goes wrong?

Use git reflog to find the commit before the rebase started, then reset to it:

# View the history of HEAD movements
git reflog
 
# Output shows something like:
abc123 HEAD@{0}: rebase finished
def456 HEAD@{1}: rebase: Add validation
ghi789 HEAD@{2}: rebase: Add login form
jkl012 HEAD@{3}: checkout: moving from feature to main
mno345 HEAD@{4}: commit: Add tests  # <- Before rebase!
 
# Reset to the state before rebase
git reset --hard HEAD@{4}

Even if you complete a rebase and realize it was a mistake, reflog keeps a record of where your branch was before. Git makes it very hard to lose work permanently.

What is the difference between git reset and git revert?

Both undo changes, but in fundamentally different ways.

git reset moves the branch pointer backward and optionally modifies the staging area and working directory. It rewrites history by making commits unreachable. This is fine for local work but dangerous for shared branches.

git revert creates a new commit that undoes the changes from a previous commit. The original commit stays in history, and the new commit documents that you undid it. This is safe for shared branches because you're adding to history, not rewriting it.

# Reset: rewrites history (local only!)
git reset --hard HEAD~2  # Remove last 2 commits
 
# Revert: adds new commit (safe for shared branches)
git revert abc123  # Create commit that undoes abc123

Rule: Use reset for local mistakes, use revert for shared branches.

What is git cherry-pick and when would you use it?

Cherry-pick copies a specific commit from one branch and applies it to another. Unlike merge or rebase, which work with entire branches, cherry-pick works with individual commits.

# Apply a specific commit to current branch
git cherry-pick abc123
 
# Apply multiple commits
git cherry-pick abc123 def456
 
# Apply without committing (stage changes only)
git cherry-pick --no-commit abc123

Use cases:

• A specific bug fix from a release branch is needed in your feature branch
• A commit was accidentally made on the wrong branch
• You want to selectively apply changes without bringing in everything else

Cherry-pick is a precision tool for specific situations rather than an everyday operation.

Workflow Questions

These questions test your understanding of real-world Git workflows.

What is the difference between merge --squash and rebase followed by merge?

Both can result in cleaner history but work differently.

git merge --squash feature takes all commits from the feature branch and combines them into a single set of staged changes. You then commit as a single commit. The original branch history isn't recorded, so you lose visibility into individual commits.

Rebase followed by merge first rebases your feature branch onto main (creating new commits in a linear sequence), then merges the rebased branch. If main hasn't moved, this is a fast-forward merge and your individual commits are preserved in the linear history.

Guideline: For a feature with logical, well-crafted commits, use rebase + merge. For a branch with messy WIP commits, squash merge gives a cleaner result.

How do you update a feature branch with changes from main?

Use rebase to maintain a linear history:

# Fetch latest changes
git fetch origin
 
# Rebase your feature branch onto main
git rebase origin/main
 
# If conflicts occur, resolve commit-by-commit
# git add <resolved-files>
# git rebase --continue
 
# If you'd previously pushed the feature branch, update remote
git push --force-with-lease

This replays your commits on top of the latest main, ensuring you're working with current code and catching integration issues early.

How do you clean up commits before creating a pull request?

Use interactive rebase to squash WIP commits into logical units:

# Rebase the last N commits interactively
git rebase -i HEAD~8
 
# In the editor:
# - Mark first commit of each logical group as 'pick'
# - Mark related commits as 'squash' or 'fixup'
# - Reorder if needed
 
# After saving, write clear commit messages for each logical group

The goal is commits that tell a clear story of what you built—each commit should represent a complete, working state with a descriptive message explaining what and why.

Quick Reference

Related Articles

• Complete DevOps Engineer Interview Guide - comprehensive preparation guide for DevOps interviews
• 5 Tricky Git Interview Questions - Git internals and advanced commands
• System Design Interview Guide - Scalability, reliability, and distributed systems
• CI/CD & GitHub Actions Interview Guide - Git workflows that trigger CI/CD pipelines