Rebase vs merge
Rebase and merge are two strategies for integrating changes from one branch into another. Merge creates a merge commit that preserves the branching history; rebase replays the branch's commits on top of the target's tip, producing a linear history with no merge commits. The choice affects readability, blame attribution, and conflict-resolution mechanics.
The pragmatic guidance: rebase for local branches before pushing, merge for shared branches. Rebasing rewrites history, which is destructive on branches other engineers depend on but harmless on private branches. The aesthetic divide: 'linear history' camps love rebase for its clean log; 'preserve actual history' camps prefer merge because rebase rewrites timestamps and obscures when work actually happened. Modern GitHub PR workflows often allow both per-PR via 'Squash and merge', 'Rebase and merge', or 'Create a merge commit'; teams that pick one and stick with it avoid the most contentious debates.
Related terms
- Squash merge
A squash merge collapses all commits on a feature branch into a single commit on main, discarding the intermediate history.
- Pull request
A pull request (PR) — also called a merge request in GitLab / Bitbucket — is a proposal to merge changes from one git branch into another, typically with code review and CI checks gating the merge.
- Gitflow
Gitflow is a branching model with long-lived develop and main branches, plus feature, release, and hotfix branches.