Tidying History with rebase (and the Golden Rule)
This is the most confusing topic in the course, so we'll go slow. Last lesson we saw merge — one way to combine work from a branch, which leaves a merge commit and keeps both lineages as they happened. Now we meet a second way, git rebase: it 'replays' your branch's commits so they start from anothe
rebase is like taking the pages you wrote and recopying them at the end of the team's updated notebook — as if you'd written them there from the start. The result looks tidy and straight, but they're new pages. So you don't recopy pages you already handed to others — they still hold the old pages, and that creates confusion.
- git rebase
- Replays the current branch's commits so they start from another branch's tip, creating linear history. The original commits are replaced by new commits with new hashes.
- Linear history
- History that is a single straight line of commits, with no forks and no merge commit — each commit sits directly on top of the one before it.
- Golden rule
- Never rebase commits you've already pushed or shared with others. rebase rewrites hashes, so it's safe only on private local work.
- Commit hash
- The unique identifier of each commit (a fingerprint). If anything in the commit changes — including its parent — it gets a new hash, and so becomes a different commit.
- Replay
- The action where rebase takes each of your commits and re-applies it, one by one, on top of the other branch's tip — this is how the new commits are created.
