Git Rebase

Git rebase moves or combines a series of commits onto a new base commit. It helps you update a feature branch, arrange local commits, and create a direct project history before sharing work.

Rebase rewrites commits. The new commits can contain the same changes, but they receive new identities because their parent history changes. Use it deliberately and avoid rebasing shared commits that teammates may already use.

How Git Rebase Changes History

Suppose main and feature/profile diverge. Rebasing the feature branch temporarily removes its commits, moves the branch to the current main tip, and reapplies the feature changes one commit at a time.

Basic rebase:

# Update local knowledge of the remote repository.
git fetch origin

# Move the current feature branch onto origin/main.
git switch feature/profile
git rebase origin/main

The command does not change origin/main. It rewrites only the commits selected from the current branch.

Check Your Work Before Rebasing

Start with a clean working tree, confirm the current branch, and inspect the commits that will be replayed.

# Confirm that no work is accidentally left uncommitted.
git status

# Review the branch graph before changing it.
git log --oneline --graph --decorate --all -15

You can commit, stash, or intentionally discard unfinished changes before continuing. A recent backup branch also provides an easy recovery point.

# Create a lightweight safety reference at the current commit.
git branch backup/profile-before-rebase

Resolve Rebase Conflicts

A conflict occurs when Git cannot automatically combine a replayed commit with the new base. Git pauses at that commit and identifies the affected paths.

1. Open each conflicted file and choose the intended content.
2. Add resolved files to the index.
3. Continue the rebase.
4. Run tests after the final commit is replayed.

# See the files that need attention.
git status

# Mark a corrected file as resolved.
git add src/profile.js

# Continue replaying the remaining commits.
git rebase --continue

If a replayed commit is no longer required, git rebase --skip omits it. Use skip only after confirming that the commit's change already exists or should genuinely disappear.

Abort a Rebase Safely

Use --abort when the chosen base is wrong, conflicts are too complex, or you want to return to the pre-rebase state.

# Stop the operation and restore the original branch state.
git rebase --abort

Do not delete conflict markers blindly. Understand both versions of the change, resolve the file, and run the relevant tests before continuing.

Clean Local Commits with Interactive Rebase

Interactive rebase opens a todo list for the selected commits. You can reorder them, edit their messages, combine related work, or remove unwanted commits before publishing the branch.

# Edit the most recent four commits.
git rebase -i HEAD~4

The todo list is ordered from the oldest selected commit to the newest. Each action operates relative to the commit above it, so a squash line cannot be the first entry.

Use Autosquash for Fixup Commits

Create a fixup commit when a small correction belongs to an earlier local commit. Interactive rebase with --autosquash places it beside its target automatically.

# Create a fixup for the selected local commit.
git commit --fixup abc1234

# Reorder and combine fixups automatically.
git rebase -i --autosquash origin/main

Rebase with --onto

The --onto form gives explicit control over the new base and the old boundary. It is useful when a branch was created from the wrong parent.

# Replay commits after develop onto main from feature/search.
git rebase --onto main develop feature/search

Read the command as: take commits reachable from feature/search but not from develop, then replay them on main.

Rebase Merge Commits

A normal rebase linearizes the selected history and does not preserve merge commits. Use --rebase-merges when the merge structure carries useful information and must be recreated.

# Recreate merge structure while rebasing onto the latest main.
git rebase --rebase-merges origin/main

Push a Rebased Branch

A previously pushed branch no longer has the same history after a rebase. If rewriting that remote branch is permitted, use --force-with-lease. It refuses the update when the remote branch has changed unexpectedly.

# Update your own rebased branch with a safety check.
git push --force-with-lease origin feature/profile

Avoid plain --force, and coordinate before rewriting any branch another person may use.

Recover Rebased Commits with Reflog

Git's reflog records recent updates to local references. If you finish a rebase and later need the old tip, find it in the reflog and create a branch there.

# Find the branch position from before the rebase.
git reflog

# Preserve the old commit once you identify it.
git branch recovery/profile HEAD@{5}

Rebase or Merge

Rebase creates a linear history by rewriting commits. Merge preserves the existing branch histories and usually adds a merge commit. Rebase is useful for private cleanup; merge is safer for integrating shared public history.

Conclusion

Git rebase replays commits on a new base and can produce a focused, readable history. Inspect the branch first, resolve conflicts carefully, use interactive actions for local cleanup, protect remote updates with --force-with-lease, and use reflog or a backup branch when recovery is needed.