Merge vs Rebase: When to Use Each Git Strategy and How They Handle Conflicts

Background and Scenario

The author describes a common development situation: two developers start separate feature/A and feature/B branches from the same master commit. Each branch makes three commits that modify the same file, guaranteeing conflicts when the branches are later merged.

Merge Workflow

First, feature/A is merged into master:

git checkout master
git merge feature/A

After the merge, master and feature/A point to the same commit, demonstrating a fast‑forward merge (no new merge commit).

When feature/B is merged:

git checkout master
git merge feature/B

The merge creates a new merge commit (a non‑fast‑forward merge) because master</b> has advanced since <code>feature/B was branched. All conflicts are presented at once and must be resolved before the merge commit is created.

Fast‑Forward vs Non Fast‑Forward

Fast‑forward merge : occurs when the branch being merged is a direct descendant of the current HEAD; no new commit is created.

Non fast‑forward merge : creates a merge commit that preserves the parallel history and may generate a merge‑request (mr) node.

Rebase Workflow

After undoing the previous merge of feature/B, the author rebases the branch onto master:

git checkout feature/B
git rebase master

During the rebase, VS Code prompts the user to resolve conflicts commit by commit. Each conflicting commit must be fixed, staged with git add, and then continued with git rebase --continue:

git rebase --continue

After the rebase finishes, the commit history becomes a straight line, eliminating the merge commit but rewriting the original commit hashes.

Key Takeaways

Merge preserves the full history, creates a non‑linear graph, and may generate merge‑request nodes; all conflicts are resolved in a single step.

Rebase rewrites history into a linear sequence, avoids extra merge commits, but requires resolving conflicts for each individual commit.

Use git rebase -i to reorder or squash commits before sharing them.

Never rebase a public/shared branch, as rewriting commit hashes will cause downstream conflicts for collaborators.

For solo work or before pushing to a remote, rebase can clean up history; otherwise, merging is safer.