Merge vs Rebase: The Ultimate Guide to Git Merge Strategies

Two developers, A and B, start separate feature/A and feature/B branches from the same master commit and each add three commits that modify the same file, guaranteeing conflicts when the branches are later merged.

Merge of feature/A

git checkout master
git merge feature/A

The merge succeeds, creating a new merge commit that aligns master with feature/A. This merge commit preserves the branch history; whether a merge‑request (MR) node appears depends on whether the merge is a fast‑forward.

Fast‑forward merge

If master has not advanced since the branch point, the merge is a fast‑forward: master simply moves to the tip of feature/A and no separate merge commit is generated.

Non fast‑forward merge

When master receives new commits (e.g., from another branch) before the merge, Git must create a merge commit that joins the two divergent histories, retaining a non‑linear graph and producing an MR node.

Merge of feature/B

git checkout master
git merge feature/B

Because every commit touches the same file, the merge triggers a single conflict resolution step. After fixing the conflict and committing, a merge commit appears, illustrating that merge resolves all conflicts at once.

Rebase of feature/B

After undoing the previous merge, the branch graph is reset to the earlier master state. Rebase is performed:

git checkout feature/B
git rebase master

VS Code prompts to resolve the first conflict. Since each commit modifies the same lines, the developer must resolve conflicts repeatedly—once per commit—using git add and git rebase --continue. This step‑by‑step replay rewrites the commit hashes, producing a linear history without a merge commit.

Resulting histories

The final graph after rebase shows a straight line of commits; the original commit hashes ( docs:3, docs:4, docs:6) are replaced by new hashes. No extra MR node is created, but the history is rewritten.

Conclusion

Merge preserves the original, non‑linear history and often creates MR nodes.

Rebase rewrites history into a linear sequence, eliminating extra merge commits but changing commit hashes.

Merge resolves all conflicts in a single step; rebase forces conflict resolution for each individual commit.

Rebase is appropriate for private, un‑pushed branches where history can be safely rewritten; otherwise, merge is the safer default.

Additionally, git rebase -i can be used to reorder or squash commits and edit commit messages.