Rebasing versus merging

Git has two main ways to integrate changes from one branch into another: merge and rebase. Merge performs a three-way merge between the two latest branch snapshots and their most recent common ancestor, creating a new merge commit. Rebase instead goes to the common ancestor, takes the diff introduced by each commit on your branch, and replays those changes in order on top of the other branch, after which the target branch can fast-forward. The snapshot you end up with is identical either way; only the history differs, and rebasing produces a linear log that looks as if the work happened in series even when it happened in parallel. That makes rebasing useful when contributing to a project you do not maintain, since the maintainer needs only a fast-forward or a clean apply. The perils reduce to one rule: do not rebase commits that exist outside your repository and that people may have based work on. Rewriting pushed commits forces collaborators to re-merge their work and makes pulling their work back into yours messy. Scope: Git. Reviewed October 4, 2026.