Git Rebase vs Merge Explainer
Pick a branch history scenario, choose Merge or Rebase, and watch what happens to your commit graph. Learn the golden rule and get the exact commands for each flow.
Step 1: Pick a scenario
Step 2: Choose your flow
Step 3: Resulting commit graph
Choose Merge or Rebase above to draw the result. Nodes appear one by one in the order they are created.
main branch
feature branch
merge commit
Pros and cons
| Advantage | Disadvantage |
|---|---|
| Select a flow to compare the tradeoffs. | |
The golden rule of rebasing: never rebase commits that already exist on a shared remote branch. Rebasing rewrites commit hashes, so anyone else who pulled the old commits will get duplicate history and painful conflicts. Rebase only your own local commits or private feature branches.
Command cheat sheet: select a flow
Choose Merge or Rebase above and the exact commands will appear here.How it works
Git gives you two ways to bring changes from one branch into another.
- Merge takes the two branch tips and creates a new merge commit that has both as parents. All original commits keep their hashes, and the history shows exactly when the branches came together.
- Rebase moves your feature commits to the tip of the target branch, replaying each one on top. The result looks like one straight line, but the replayed commits are brand new objects with new hashes.
- The simulator above draws the same scenario twice so you can see the difference: merge adds a merge commit, rebase rewrites your commits with new hashes (shown with a prime mark).
- The animation order follows real Git behavior: for merge, commits are linked to the merge commit; for rebase, each feature commit is applied one at a time on top of main.
Everything here is a teaching model, not real Git output, but the structure matches what you would see with git log --graph.