Week 7 · Lesson 10 of 10

Rebasing for a Linear History

0% Complete

Core Idea

Rebase updates a branch by changing its base and replaying its commits on top of another branch's newer commits.

It is an alternative to bringing one branch into another through a merge commit. The project content can be brought up to date while the commit history is arranged as a cleaner, more linear sequence.

How It Works

Suppose a feature branch is created from main. Work then continues independently:

  • The feature branch receives a commit for feature functionality.
  • Main receives a separate commit for a new interface update.

The feature branch now lacks the newer main commit.

Switch to the feature branch:

git checkout feature

Rebase it onto main:

git rebase main

Git performs the operation conceptually in four stages:

  1. Identify the most recent commit shared by feature and main.
  2. Temporarily set aside the feature commits that came after that common point.
  3. Apply the newer main commits to the feature branch's base.
  4. Reapply the saved feature commits one by one on top of the updated base.

The resulting feature branch contains the latest main changes followed by the feature work. The history reads as though the feature work began from the newer main state.

Comparison with Merge

In the illustrated merge workflow, merging main into a feature branch can add a merge commit that records the branch combination.

Rebase avoids that branch-joining commit by replaying the feature commits after the newer main commits. Running git log then shows a more linear history.

The code content can be brought to the same combined state through either approach, but the history structure differs.

Why It Matters

Repeated merge commits can make a history more difficult to scan. Rebase can make a local feature branch easier to read by placing its commits after the latest main commits in a single line.

This is useful when one developer owns a local or personal feature branch and wants to update it before later integration.

The mechanism also clarifies why rebase requires caution: replaying commits creates rewritten commits. Their identifiers change because the branch history has been reconstructed on a new base.

Practical Application

A rebase workflow is:

  1. Create a feature branch from main.

git checkout main git branch feature git checkout feature

  1. Make and commit feature work.

git add . git commit -m "Add feature functionality"

  1. Allow main to receive newer commits through other work.
  2. Return to feature.

git checkout feature

  1. Rebase feature onto the updated main branch.

git rebase main

  1. Inspect the result.

git log --oneline

The log should show the newer main commits followed by the replayed feature commits.

Decision Logic

Use rebase when:

  • The branch is local or personal.
  • You want the branch to begin from the latest main state.
  • A linear history is preferred.
  • Rewriting the branch's commit IDs will not disrupt collaborators.

Avoid rebasing shared public history when:

  • Multiple developers are working from the same branch.
  • The commits already exist on a shared remote branch.
  • Other local copies depend on the existing commit IDs.

If rebase must be used in a collaborative setting, the team should be informed before the history is rewritten.

Trade-Offs and Limitations

Rebase produces a cleaner linear history, but it rewrites existing commits and changes their identifiers.

When another developer has the original versions of those commits, the rebased branch no longer matches that developer's local history. Normal synchronization can then become difficult.

For that reason, rebase is presented as safe for local or personal branches where only one person is working, but risky on shared remote branches.

Merge preserves the visible fact that branches were combined. Rebase presents the work as a linear sequence. The choice is therefore not only about final file content; it is also about the history that collaborators will see and depend on.

Key Takeaway

Run rebase from the branch being updated and name the branch that should become its new base. Use it to maintain a linear local history, but do not rewrite commits that collaborators already share unless the team has coordinated that decision.

Back to top