Rebasing is reapplying commits from one branch onto another, creating a linear history. Instead of merging—which preserves both branches' histories—rebasing replays your commits on top of the target branch, as if you had started from that point. Use it to keep feature branches up to date or to clean up messy histories before merging.

Rebasing rewrites commit hashes, so the golden rule is: never rebase commits that are already pushed to a shared branch. If you rebase and then push, teammates who branched from your old commits will have a broken history. Only rebase your own local commits or on branches that no one else is using.

$ git rebase <branch>        # reapply commits from current branch onto <branch>
$ git rebase -i HEAD~3       # interactive rebase: edit, reorder, squash last 3 commits
$ git rebase --abort         # cancel a rebase if something goes wrong
$ git rebase --continue      # resume after resolving conflicts

A common workflow is to rebase your feature branch onto the latest main before merging, so the merge is a simple fast-forward with no merge commit. This produces a clean, linear history. When rebasing interactively, you can squash multiple small commits into one logical commit or edit commit messages before pushing.