Rebase

Rebase rewrites a branch by replaying its commits on top of a different base commit.

This means Git takes commits from one line of work and reapplies them as new commits somewhere else in history.

What rebasing changes

Suppose your feature branch started from an older commit, but main moved forward with new work.

When you rebase your feature branch onto the newer main, Git replays your feature commits on top of that newer base. The branch often ends up looking more linear, as if the feature work had started from the newer point all along.

That can make history easier to read, but it also means the rebased commits are new commits, not the exact same ones as before.

Merge vs rebase

Both merge and rebase are ways to combine lines of development, but they do it differently.

Merge keeps the existing branch histories and joins them together, often with a merge commit.

Rebase rewrites one branch so its commits are replayed on top of another base.

In practical terms:

• Merge preserves the original branch structure.
• Rebase creates a cleaner, more linear history.
• Rebase changes commit identities because it creates replacement commits.

Neither approach is universally correct. Teams choose based on their workflow and preferences.

Why rebasing rewrites history

This is the most important caution about rebase.

Because Git is replaying commits as new commits, the rebased branch no longer has the exact same commit history as before. Even if the file contents end up the same, the commit hashes change.

That is why people say rebase rewrites history.

When rebase is commonly used

Rebase is often used to:

• Move a feature branch onto the latest main.
• Clean up local history before sharing it.
• Avoid unnecessary merge commits in a branch's history.

Rebasing local commits that only exist in your own repository is usually straightforward. Rebasing commits that other people already rely on requires more care.

Be careful with shared history

As a rule of thumb, rebasing unpublished local work is much safer than rebasing commits that were already pushed and used by collaborators.

If you rewrite shared history, other people may suddenly be working from a branch history that no longer matches yours.

That does not mean rebasing pushed work is never possible, but it does mean you should understand the consequences before doing it.