Textbook of Linux

Rebasing replays the commits of a branch onto a new base commit, producing a linear history instead of the branching-and-merging graph. Where a merge says "here is where these two streams came together", a rebase says "pretend I wrote this work on top of the latest main". The result is cleaner, more linear history at the cost of rewriting commit hashes.

git switch feature
git rebase main                    # replay feature on top of main
git rebase -i HEAD~5               # interactive: reorder, squash, edit last 5
git rebase --abort                 # give up
git rebase --continue              # after resolving conflicts

Interactive rebase (git rebase -i) is one of git's most powerful features: you can reorder, squash, edit, or drop commits before they become permanent. It is invaluable for tidying up a messy feature branch before opening a pull request.

The golden rule of rebasing: never rebase commits that have been pushed to a shared branch. Because rebasing creates new commit hashes, other people's clones will diverge from yours, and the ensuing confusion is no fun to recover from. Rebase your local branches freely; leave shared branches alone. When in doubt, merge instead.