Rebase a local branch onto the latest remote main

Fetch the target branch, replay your feature commits, resolve conflicts, and publish rewritten history with an explicit understanding of the remote state.

Best practices
Illustration of Git branches and version history

Fetch the remote, then run git rebase origin/main while on your feature branch. Git replays the relevant feature commits on the fetched mainline. Substitute origin/master if that is your repository's branch name.

Fetch and rebase

Start with a clean working tree and inspect any local or remote divergence:

git switch feature-x
git status --short
git fetch origin
git branch backup-before-rebase
git rebase origin/main

The backup ref retains the original tip. The command does not update the remote branch; it changes your local history. Already-applied changes may be omitted during replay, so inspect the result and run tests.

For a conflict, edit the affected files and stage the resolution:

git add -- src/app.js
git rebase --continue
# To abandon an active rebase instead:
git rebase --abort

Abort restores the starting branch state of the active rebase. Keep any new edits you want before aborting; it is not an unlimited undo mechanism after completion.

Choose rebase or merge

Consideration Rebase onto origin/main Merge origin/main
Existing feature commits Replayed commits receive new identities Existing commit identities remain
Shape of history Usually linear; merge preservation needs explicit options May fast-forward, be up to date, or create a merge commit
Published feature branch A rewritten tip may need a coordinated non-fast-forward update Usually permits a normal push
Typical fit Private feature work Shared or long-lived work

Neither approach replaces tests or review. Keep feature branches reasonably short-lived and integrate changes at a cadence that suits the team.

Publish a rewritten personal branch

Before rebasing a published branch, fetch and inspect its tip, then record the exact remote-tracking commit you have reviewed. After a successful rebase, an explicit lease can use that recorded value:

# Record this before rewriting, after inspecting the fetched remote state.
expected=$(git rev-parse refs/remotes/origin/feature-x)
# Run the rebase and tests before this push.
git push --force-with-lease=refs/heads/feature-x:"$expected" origin HEAD:refs/heads/feature-x

If the remote changes, the lease rejects the update. Do not refresh the expected value merely to make the push pass: inspect the newly published work. A lease does not protect collaborators' unpublished commits, and branch protection may forbid rewriting entirely.

Reduce repeated conflict work

git config --local rerere.enabled true lets Git record and reuse conflict resolutions. Review reused resolutions; a textually matching conflict can still need different semantics.

If teammates already based work on the old branch, coordinate recovery. They should save their own work and compare old and new histories before rebasing or cherry-picking their remaining commits. A blind reset --hard origin/feature-x can discard their changes.

See git-rebase, git-push leases, and git-rerere.

Get a tailored plan

Contact us

Join the community

Scan with WeChat
to join the community

Try Guance

Start online and pay only for what you use.

Get started

Choose a Guance plan

Code hosting