Lesson 30 of 51 ~30 min
Course progress
0%

Rebasing – Rewriting History

Master Git's powerful rebasing feature to create clean, linear project histories. Learn interactive rebasing, squashing commits, and when to use vs avoid rebasing.

1 Why Git and How It Thinks Differently Than Other VCS 2 The Anatomy of Git — Commits, Blobs, Trees, SHA-1, HEAD, and the Staging Area 3 Installation and Basic Configuration 4 First Repo – From Init to First Push 5 Everyday Work – Add, Commit, Status, Diff 6 .gitignore and Working with Files 7 Branching Basics – Create, Switch, Merge 8 Merging and Conflict Resolution 9 Rebasing – Rewriting History 10 Visualizing Git History – Log, Graph, Tools 11 Remotes – Push, Fetch, Pull 12 Handling Conflicts Like a Pro 13 Tags and Versioning 14 Cherry-pick, Revert, Reset 15 Stashing and WIP Strategies 16 Bisect – Debugging Through History 17 Submodules and Git LFS 18 Git Hooks and Automation 19 Aliases and Shortcuts 20 Team Workflows – GitHub Flow, GitFlow, Trunk-based 21 Git and CI/CD Integration 22 Troubleshooting Git Problems 23 Copilot Instructions for Git 24 Best Practices and Checklists 25 Conclusion – Git as a Mindset

If merging is jazz, rebasing is editing. A merge preserves every improvisation, while a rebase rewrites the tune into a clean melody. Rebasing is one of Git’s most powerful and controversial features. It can transform tangled histories into linear stories, but misused it can rewrite other people’s work and cause chaos. In this chapter, we’ll explore rebase deeply: what it does, when to use it, when not to, and how interactive rebasing gives you the editor’s pen.

The Concept of Rebase

Rebase means “change the base.” Instead of merging one branch into another, you take commits from one branch and replay them on top of another. The result is a linear history without merge commits.

Visualization:

gitGraph
  commit tag: "A"
  commit tag: "B"
  branch feature
  checkout feature
  commit tag: "C"
  checkout main
  commit tag: "D"
  checkout feature
  commit tag: "C′ (rebased)"
  merge main

Now commits C are replayed after D, giving a straight line.

Basic Rebase

git checkout feature
git rebase main

This takes commits from feature and applies them on top of main. If there are conflicts, you resolve them, then continue:

git add conflicted_file.py
git rebase --continue

Before and After Visualization

Before:

gitGraph
  commit id: "A"
  commit id: "B"
  branch feature
  checkout feature
  commit id: "C"
  checkout main
  commit id: "D"

After rebase:

gitGraph
  commit id: "A"
  commit id: "B"
  commit id: "D"
  commit id: "C'"

Notice that C' is a new commit (different hash). Rebase rewrites history.

Interactive Rebase

Interactive rebase is history surgery. You can reorder commits, squash them together, edit messages, or even drop commits.

git rebase -i HEAD~3

This opens an editor with lines like:

pick a1b2c3 add feature A
pick d4e5f6 fix typo
pick g7h8i9 add tests

You can change commands:

  • pick → keep commit.
  • squash → combine with previous.
  • edit → pause to amend.
  • drop → remove commit.

This lets you craft history as if it always happened perfectly.

Squashing Commits

Instead of 5 messy commits like “fix typo,” “oops,” “really fix typo,” you can squash them into one clean commit.

git rebase -i HEAD~5

Mark extras as squash, edit the message, and voilà—history looks clean.

Editing Commit Messages

Interactive rebase also lets you fix sloppy commit messages:

pick a1b2c3 initial
reword d4e5f6 oops

This reopens the message editor so you can write something meaningful.

When to Use Rebase

  • Before pushing: Clean up local history before sharing.
  • To avoid merge commits: Keep history linear.
  • For polishing: Rewrite work into logical commits.

When Not to Use Rebase

  • On shared branches: Rewriting history others depend on causes pain.
  • On public history: Never rewrite commits already pushed.

Golden rule: rebase private, merge public.

Solo Workflow Example

As a solo dev, you experiment wildly, then squash messy commits into elegant milestones before pushing.

git rebase -i HEAD~10

Result: polished history that feels like a curated story.

Team Workflow Example

On a team, you rebase your feature branch onto main before opening a pull request:

git checkout feature
git fetch origin
git rebase origin/main

This ensures your branch plays nicely with the latest changes, reducing merge conflicts.

Visualization:

flowchart TD
  Main[origin/main commits] --> Feature[feature branch commits]
  Feature --> Rebased[feature rebased on top of main]

Handling Conflicts in Rebase

Conflicts during rebase are resolved step by step. Git pauses, you fix, stage, continue. If things go wrong, you can abort:

git rebase --abort

Think Different Mindset

Rebase teaches us that history is malleable. It’s not just a record—it’s a story you can edit. But with that power comes responsibility. Rewrite your own drafts, never someone else’s. Think of rebase as editing your diary before publishing, not altering the shared chronicle of your team.

Rebase is one of Git’s sharpest tools. Used well, it makes history elegant and comprehensible. Used carelessly, it creates chaos. The mantra to remember: merge for collaboration, rebase for curation. Master this, and you’ll move from Git user to Git storyteller. Next, we’ll explore how to visualize history and make sense of the DAG itself.