git rebase, keeping track of 'local' and 'remote'
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
The confusion around git rebase usually comes from mixing up three different things: your current local branch, the remote-tracking branch such as origin/main, and the branch that exists on the server. Rebase only rewrites local commits, but it often uses remote-tracking references as the base for that rewrite.
The References Git Is Actually Using
Suppose you are on feature/login and the remote repository has a main branch. Git may show all of these names at once:
- '
feature/loginis your local branch' - '
origin/feature/loginis your local record of the remote branch state' - '
mainis your local branch, if you have one' - '
origin/mainis your local record of the remotemain'
The origin/... names are not live network pointers. They update when you run git fetch.
That means this command sequence is the normal starting point:
git fetch origin updates your local knowledge of the remote repository. git rebase origin/main then replays your local feature/login commits on top of that updated base.
What Rebase Changes
Rebase does not change origin/main. It does not change the remote server directly either. It creates new versions of your local commits with new parent commits.
Before rebase, the history may look like this:
After git rebase origin/main, it becomes:
The content may be the same, but D' and E' are new commits. That is why rebase is described as history rewriting.
Local Branch Versus Remote Branch After Rebase
After rebasing, your local feature/login no longer matches origin/feature/login. The remote-tracking branch still points to the older commit chain until you push.
If this feature branch already exists on the server, you usually need:
Use --force-with-lease, not plain --force. It refuses to overwrite the remote branch if someone else pushed new commits that you have not seen.
A Safe Everyday Workflow
A practical rebase workflow for feature branches is:
That gives you a clean local main and rebases your feature branch onto the latest remote state.
If conflicts occur, Git stops and asks you to resolve them.
If the rebase is going badly, abort it.
When Rebase Is a Bad Idea
Rebasing a private feature branch is usually fine. Rebasing a shared branch that multiple people are already building on is risky because everyone else now has the old commit IDs.
That does not make rebase wrong. It means you should rebase branches you control and coordinate carefully before rewriting anything collaborative.
Also note that rebasing your local branch does not magically update a pull request until you push the rewritten branch.
Common Pitfalls
The most common mistake is rebasing onto stale information because git fetch was skipped. If origin/main is old, your rebase is based on old history.
Another mistake is thinking origin/main is the remote server itself. It is just your local cached reference to that branch.
A third mistake is force-pushing without understanding who else uses the branch. If teammates already based work on the old commits, their history becomes awkward to recover.
Finally, people often forget that rebase rewrites commit IDs. If you have already published those commits widely, a merge may be the safer option.
Summary
- '
git rebaserewrites local commits on top of a new base.' - '
origin/mainis a local remote-tracking reference updated bygit fetch.' - Rebase does not change the remote branch until you push.
- After rebasing a published feature branch, push with
--force-with-lease. - Rebase private branches freely, but coordinate before rewriting shared history.
- If conflicts become messy, use
git rebase --abortand start again.

