rebasing

Rebasing is a technique in version control that moves a sequence of commits to begin at a new base commit. It replays the changes introduced by those commits onto another branch or commit, creating a linear history rather than a graph with merge commits. In effect, the commits themselves are preserved, but their parentage is rewritten.

Rebasing differs from merging in purpose and history. A merge combines two branches and preserves the original commits, resulting in a merge commit that reflects both histories. Rebasing, by contrast, reapplies commits on top of another branch, which can produce a cleaner, linear history but rewrites commit IDs. Because of this rewrite, rebasing published or shared branches can disrupt collaborators who have based work on the old commits.

Typical usage involves updating a feature branch with the latest changes from a main branch. A common workflow is to fetch updates and then rebase the feature branch onto the latest main. If conflicts arise, they must be resolved and the rebase continued. An interactive rebase, invoked with a flag such as -i, allows editing, reordering, squashing, or dropping commits before finalizing.

Implications and cautions include the fact that rebasing rewrites history. This can complicate collaboration if others have pulled the original commits. It is generally safer to rebase local or private branches and communicate with teammates when rebasing public history. When pushing after a rebase, a force-with-lease option is often used to update the remote branch while protecting against overwriting others’ work.

Variants and related techniques include merging, which preserves history without rewriting commits, and cherry-picking, which applies individual commits without rebasing an entire branch. Interactive rebasing provides granular control over commit structure.