Rebase

Learn how git rebase rewrites commits onto a new base and when to use it carefully.

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.

Interactive rebase in GitComet

Check out the branch you want to edit and commit or stash unfinished work.
In history, right-click the commit before the commits you want to rewrite and choose Interactive rebase …. The selected base itself is excluded. To edit only the latest commit, start from its parent.
Drag commits to reorder them and choose an action for each entry.
Review the resulting order and messages, then choose Start Rebase.

Action	Result
Pick	Replay the commit.
Reword	Replay it with an edited commit message.
Squash	Combine it with the previous commit and combine their messages.
Fixup	Combine it with the previous commit and discard its message.
Drop	Leave it out of the rewritten history.

Auto Squash groups commits by their subjects, recognizing fixup!, squash!, and amend! prefixes when finding matching commits. Review the grouped result before starting the rebase. GitComet also offers Squash … commits for eligible contiguous selections in history, with a preview of the resulting message.

If the rebase stops at a conflict, resolve and stage the affected files, then continue the rebase. Use the rebase abort action to return to the state before the operation.

For moving a branch onto a different base without editing its commit list, use Rebase Onto from the command palette or the rebase action on the target branch or commit.