Merge vs Rebase

About

Feature	Merge	Rebase
What it does	Integrates changes from one branch into another by creating a new merge commit that records the union of both histories.	Moves the entire set of commits from your branch and reapplies them on top of another branch (usually the main one).
Effect on commit history	Preserves true historical timeline. You can see when and how two branches diverged and then merged.	Rewrites history by changing the base of your branch, as if the commits were made sequentially on top of the target branch.
Structure of history	Creates a non-linear history that shows the full branching structure and context of collaboration.	Creates a linear history that appears clean and ordered but loses details of when branches actually diverged.
How it affects commits	Keeps all existing commit hashes unchanged and adds one new commit (the merge commit).	Changes commit hashes, dates, and potentially the order of commits, because commits are recreated during rebase.
Context preservation	Preserves full historical context, including how and why branches were developed separately.	Loses the branching context — the rebased history looks like it happened in a straight line, regardless of the actual timeline.
Commit graph appearance	You'll see branches merging back together with clear visual splits and merges in tools like Git log or GitKraken.	You'll see a single line of commits with no sign that a separate branch ever existed.
Typical usage scenario	Used when integrating completed features or hotfixes back into main branches like main or develop.	Used when you want to clean up or prepare your feature branch before merging or submitting a PR.
Team collaboration	Preferred in teams where multiple people work on the same branch — merge preserves everyone’s work cleanly.	Risky in shared branches — if you rebase after pushing, it creates problems for teammates pulling your changes.
Conflict resolution	Conflicts (if any) occur once at the merge point, and the resolved state is committed with a merge commit.	Conflicts can happen at each commit being rebased, requiring step-by-step conflict resolution.
Use on shared branches?	Safe and encouraged. Maintains stable collaboration and conflict resolution workflow.	Not safe after pushing to shared branches. Should only be done locally before pushing to avoid disrupting others.
Undo capability	Easy to revert using git revert -m 1 <merge-commit> or by resetting to a previous known commit.	Harder to undo if pushed — rebased commits differ from original, making rollback complex.
Does it rewrite history?	No. It simply adds to the existing commit graph.	Yes. It literally changes commit history by creating new versions of existing commits.
Best used when	You want to maintain full visibility of parallel development paths.	You want a streamlined, clean history that appears as if all changes happened in sequence.
Impact on Git log	Git log shows all merges and branches, giving you full traceability of how work was done.	Git log shows a linear stream of commits, hiding how work was divided across branches.
Impact on Pull/Merge Requests	Merge commits provide clear indicators of when a PR was integrated and allow for easier PR traceability.	Rebased branches appear as if they were part of main all along — PR merge points disappear.
Command used	git merge <branch>	git rebase <branch>
Risk of error	Low. Merge is a conservative operation that doesn’t change past history.	Medium to High. Rebase can be dangerous if misunderstood, especially when used after pushing.
Fast-forward behavior	If no other changes exist, Git will fast-forward the branch pointer without creating a merge commit (unless using --no-ff).	Rebase achieves a fast-forward-like effect by restructuring commits ahead of time.
How Git views them internally	A merge is a new commit with two or more parents.	A rebase is a replay of commits, as if they were written from scratch on a new base.
Common in open-source projects?	Yes. Many projects prefer merge to maintain an auditable history of PRs.	Sometimes used in PR cleanups, but usually done before opening a PR, not after.
Effect on history integrity	Maintains a complete and truthful project history, ideal for auditing and debugging.	Creates a linear but rewritten history, good for small teams or solo developers.
Golden rule	Use merge for shared work, and when preserving historical collaboration matters.	Use rebase for cleaning up local work, and when preparing for clean integration.