Git Rebase vs. Merge: Choosing the Right Workflow

git merge and git rebase both bring changes from one branch into another, but they leave very different traces in your history.

Merge preserves history exactly as it happened

git checkout main
git merge feature-branch

This creates a merge commit with two parents, preserving the actual chronological history of both branches — you can always see exactly when feature-branch was integrated and what commits it contained. The tradeoff is a history that branches and merges constantly, which can be noisy on a busy repository.

Rebase rewrites history onto a new base

git checkout feature-branch
git rebase main

This replays feature-branch's commits one by one on top of the current tip of main, producing a linear history with no merge commits. The result reads as if feature-branch had been written starting from today's main, which makes git log and git bisect much easier to follow — but it rewrites commit hashes, which is only safe for commits that haven't been pushed and shared yet.

A common convention

Many teams rebase local feature branches to keep them up to date with main during development (an interactive rebase is also useful here for squashing "fix typo" commits before opening a pull request), then merge the finished feature branch into main with a single merge commit that marks the point of integration. This gets a clean, linear feature history without ever rewriting commits that have already been pushed to a shared branch.

The one hard rule: never rebase commits that other people have already pulled. Rebasing rewrites commit hashes, so anyone who based work on the old commits will hit confusing conflicts the next time they pull.