Merge vs Rebase: When to Use Each Git Strategy for Clean History

Merge Branches

Merge creates a new merge commit that preserves the history of both branches, keeping a complete log of all changes. This results in a potentially tangled commit graph when many merges occur.

Typical workflow for merging a dev branch into main:

git checkout main
git pull origin main
git merge dev
# resolve conflicts if any
git commit -m "Merge dev into main"
git push origin main

Rebase Branches

Rebase reapplies commits from one branch onto another, rewriting history to produce a linear sequence without a merge commit.

Typical workflow for rebasing dev onto main:

git checkout dev
git pull origin dev
git rebase main
# resolve conflicts if any
git rebase --continue
git push origin dev --force

Squash Commits

During a rebase you can squash multiple commits into a single one, cleaning up the history. For example, three commits A, B, C on a feature branch become a single commit F after squashing.

Command to squash the last three commits:

git checkout dev
git rebase -i HEAD~3
# In the editor change "pick" to "squash" for the commits to combine
# Save and edit the commit message, then:
git push origin dev --force

Choosing the Right Method

Use merge when you want to retain full branch history and don’t mind merge commits, which is useful for collaborative teams tracking individual work.

Use rebase when you prefer a clean, linear history, suitable for projects that value a tidy commit log.

The choice depends on the workflow, team conventions, and the project's branching strategy.