Git
Git Rebase
Version Control
Local and Remote Branches
Software Development

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/login is your local branch'
  • 'origin/feature/login is your local record of the remote branch state'
  • 'main is your local branch, if you have one'
  • 'origin/main is your local record of the remote main'

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:

bash
git checkout feature/login
git fetch origin
git rebase origin/main

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:

text
A---B---C origin/main
     \
      D---E feature/login

After git rebase origin/main, it becomes:

text
A---B---C origin/main
         \
          D'---E' feature/login

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:

bash
git push --force-with-lease origin feature/login

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:

bash
1git checkout main
2git fetch origin
3git reset --hard origin/main
4
5git checkout feature/login
6git rebase origin/main

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.

bash
1git status
2# edit files
3git add path/to/resolved-file
4git rebase --continue

If the rebase is going badly, abort it.

bash
git rebase --abort

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 rebase rewrites local commits on top of a new base.'
  • 'origin/main is a local remote-tracking reference updated by git 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 --abort and start again.

Course illustration
Course illustration

All Rights Reserved.