Rebasing vs Merging

Analogy categoryAnalogies

Both git merge and git rebase solve the same fundamental problem — integrating changes from one branch into another — but they produce very different history shapes and carry different risk profiles. Merging preserves history exactly as it happened, including all the branching and merging points, at the cost of a more tangled graph. Rebasing rewrites your branch's commits so they appear to have been made sequentially on top of the target branch, producing a clean, linear history at the cost of generating entirely new commit objects with new hashes. Choosing between them is less about correctness and more about which trade-off a team values for its history.

🏏

Cricket analogy: This is like choosing between keeping a match's full ball-by-ball history including every rain delay and DLS recalculation (merge), versus presenting the innings as if it were played straight through without interruption (rebase) — both give a valid result, but one preserves the messy truth and one presents a clean narrative.

How rebase actually works

git rebase <base> takes the commits unique to your current branch, temporarily sets them aside, resets your branch to match <base>, and then replays each of your original commits one at a time on top of that new base — applying each as a diff and creating a brand-new commit object for it. Because these replayed commits have different parent hashes than the originals, they are entirely new commits with new SHA-1 identifiers, even though their content (the diff they introduce) may be identical. This is the crucial fact that explains rebase's most important rule.

🏏

Cricket analogy: This is like a batter replaying each shot from a rain-interrupted innings individually onto a freshly reset pitch condition — each shot (commit) is reapplied one at a time as if played under the new conditions, producing a fresh set of deliveries even though the shot selection is identical.

The golden rule of rebasing

Because rebasing rewrites commit history, you should never rebase commits that other people have already fetched or based work on. If a shared branch's history is rewritten and force-pushed, every collaborator who already has the old commits will find their local history has diverged unrecoverably from the remote, typically producing confusing duplicate commits or failed pushes when they try to sync. The safe rule of thumb: rebase freely on your own local, not-yet-shared feature branches; use merge (or ask collaborators to coordinate a shared rebase carefully) for branches others depend on.

🏏

Cricket analogy: This is like a captain never rewriting the official scorecard of a match that's already been broadcast and recorded by every news outlet — once fans and commentators have the official record, rewriting it just to look cleaner causes chaos when everyone's own notes no longer match the new version.

bash

# Merge approach: preserves exact history, creates a merge commit
$ git switch feature/notifications
$ git merge main

# Rebase approach: replays feature commits on top of latest main
$ git switch feature/notifications
$ git rebase main
Successfully rebased and updated refs/heads/feature/notifications.

$ git log --oneline --graph -4
* 3f2e1d0 (HEAD -> feature/notifications) Add push notification handler
* 9c8b7a6 Wire notification service into user settings
* 7d6e5f4 (main) Fix off-by-one error in pagination
* 4a3b2c1 Initial API scaffold
# ^ note: perfectly linear, no merge commit

# After rebasing a branch already pushed to a shared remote,
# a force-push (with lease, for safety) is required:
$ git push --force-with-lease origin feature/notifications

Interactive rebase (git rebase -i) is the same mechanism used for a normal rebase, but lets you reorder, squash, reword, or drop individual commits during the replay — it's a general-purpose history cleanup tool, not only a way to change a branch's base.

Never run git rebase (or force-push its result) on a branch like main or develop that other people are actively pulling from — doing so rewrites shared history and will corrupt collaborators' local repositories, typically requiring painful manual recovery.

Merging preserves exact history and creates a two-parent merge commit; rebasing rewrites commits to sit linearly atop a new base.
Rebased commits are brand-new objects with new SHA-1 hashes, even if their diff content is unchanged from the originals.
The golden rule: never rebase commits that have already been shared with, and possibly built upon by, other collaborators.
Interactive rebase (-i) extends the same replay mechanism to let you reorder, squash, reword, or drop commits.
A rebased branch that was already pushed requires a force-push, ideally --force-with-lease for safety against overwriting others' work.
Neither approach is universally 'correct' — merge favors history fidelity and safety, rebase favors a clean, linear, easy-to-read log.