Rebase vs merge

Rebase: replay instead of join

While you built your feature branch, main moved ahead. Merge is one answer, but on a busy team main moves daily, and merging it into your branch again and again fills the history with merge commits until the graph reads like tangled wiring — harder for humans to follow and slower for tools like git bisect (unit 10) to walk. Rebase was invented to take main's updates while keeping history a straight line:

$ git switch add-search
$ git rebase main
Successfully rebased and updated refs/heads/add-search.

Rebase lifts your branch's commits off their old starting point and replays them, one by one, on top of main's newest commit. The result reads as if you had started your work this morning from the latest main: a perfectly straight history with no merge commit.

The crucial fine print: replayed commits are new copies with new hashes. The old commits aren't moved, they're re-created, and rebase quietly abandons the originals. Same changes, same messages, different identities. Hold onto that fact, it decides when rebase is safe.

Choosing, and the golden rule

The golden rule of rebase: never rebase commits you have already pushed to a shared branch. Teammates have the original commits. Rebase hands you renamed copies, and the next push or pull becomes a collision between two versions of the same history, a genuinely miserable mess to untangle.

The safe, everyday pattern: rebase your own local, unpushed branch onto fresh main as often as you like, then merge or open the PR (lesson 8-1). Local rebase, shared merge. Teams differ in taste beyond that, follow yours.