Rebase vs Merge
Understanding the difference between a clean linear history and a complete contextual history.
Merge vs Rebase
**Merge**: A non-destructive operation that takes the contents of a source branch and integrates them into a target branch by creating a single new 'merge commit.'
**Rebase**: A history-rewriting operation that moves the entire feature branch to begin on the tip of the main branch. Instead of a merge commit, it creates brand new commits for each original commit.
Why it matters
Choosing between rebase and merge dictates a team's collaboration convention.
**Merge** prioritizes a Complete History: It shows exactly when and how features were integrated, but can pollute the history with extra merge commits.
**Rebase** prioritizes a Clean History: It eliminates unnecessary merge commits, creating a pristine timeline that simplifies debugging (e.g., using git bisect).
How it works
**Merge** integrates branches by creating a new commit that ties together the histories of both branches. Visually, this creates a diamond shape in the commit graph.
**Rebase** detaches the feature branch commits from their original starting point and re-applies them one-by-one onto the latest commit of the target branch. Visually, this results in a perfectly linear line.
Check yourself
Pick an answer to lock it in, then read why. Getting one wrong is part of how it sticks.
Remember this
- Merge creates a non-destructive merge commit (diamond shape).
- Rebase rewrites history to create a linear path.
- Merge preserves complete context; rebase prioritizes clean history.
- Never rebase a public branch that others are using.
Done with this concept?
Mark it complete to track your progress. No login needed.