Git Merge vs Rebase: When to Choose Each Strategy
This article walks through a common Git workflow where two developers work on parallel feature branches, compares the outcomes of using merge and rebase—including fast‑forward behavior, merge‑commit creation, conflict resolution steps, and the impact on commit history—so you can decide which method fits your scenario.
Scenario
Two developers, A and B, start from the same master commit and create feature/A and feature/B branches. Each branch adds three commits that modify the same file, guaranteeing conflicts when the branches are later merged.
Merge workflow
Developer A merges first:
git checkout master
git merge feature/AThis creates a merge commit, aligning master with feature/A while preserving the branch history.
When developer B merges:
git checkout master
git merge feature/BBecause all commits touch the same file, a conflict occurs. Resolve the conflict, stage the files, and commit; Git records a merge commit (often called an “mr node”).
Fast‑forward merge occurs when master has not advanced beyond the branch’s starting point; Git simply moves the master pointer forward without creating a merge commit.
Non fast‑forward merge occurs when master has new commits, requiring a merge commit to combine divergent histories.
Rebase alternative
Undo B’s merge (for example with git reset --hard HEAD~1) and rebase B onto the updated master:
git checkout feature/B
git rebase masterThe rebase stops at the first conflicting commit. Resolve the conflict, stage the files, and continue:
git add <files>
git rebase --continueIf each of B’s three commits introduces a conflict, you must repeat the resolve‑add‑continue cycle three times. Rebasing rewrites B’s commit hashes, producing a linear history without a merge commit.
Key differences
Merge preserves the original, non‑linear history and creates a merge commit when needed.
Rebase creates a linear history, eliminates extra merge commits, but changes commit hashes.
Merge resolves all conflicts in a single merge step; rebase forces you to handle conflicts for each individual commit.
Use rebase only on private, un‑pushed branches to tidy history. For shared or public branches, prefer merge to avoid rewriting shared commit hashes.
The interactive rebase command git rebase -i can reorder, squash, or edit commit messages before pushing.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
Architect's Tech Stack
Java backend, microservices, distributed systems, containerized programming, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
