Rebasing vs. Merging

Two commands bring a stale branch up to date, and they produce completely different histories. This module makes the choice deliberate instead of habitual — and teaches the one rule that makes rebase safe.

Why This Module Matters

Your test branch is four days old. main has moved eleven commits since you cut it. You need those eleven commits, and you have two ways to get them.

git merge main records what actually happened: two lines of work met at a point. git rebase main tells a different story: it pretends your work started from today's main all along, replaying your commits on top of it.

Neither is right in general. Merge preserves the truth and costs you a knotted graph. Rebase gives you a straight, readable line and costs you the truth — plus, if you do it to the wrong branch, it costs your colleague an afternoon.

For a tester, this shows up in two very practical places. Reading git log --graph on a merge-heavy repository to reconstruct when a regression landed is much harder than reading a linear one. And a rebased branch you already pulled will fight you the next time you pull it.

What You'll Learn

• What rebase does step by step: replay, not move
• Why the commit IDs change and what that implies
• Rebasing your own branch onto a fresh main from start to finish
• The Golden Rule — never rebase commits that exist on someone else's machine
• What --force-with-lease is, and why it is not the same as --force
• A decision table for choosing merge or rebase in the situations a QA actually meets

Pro Tip

Before any rebase, run git log --oneline main..HEAD. That is the exact list of commits about to be replayed. If it contains anything you did not write, stop and read Lesson 3 again.