Git & Version Control

Rebasing & History

Reshape history for a clean, reviewable log.

40 min read intermediate 3 objectives

Status

Not started

What you will learn

  • Rebase vs merge
  • Interactive rebase
  • When not to rebase

New to this? Start here

The basics, in plain English

Over time a project’s history can get messy. Rebasing is a way to tidy and reorder your commits so the story of the project reads cleanly. It is powerful, so there are a few safety rules.

History
The ordered list of all commits, telling the story of how the code evolved.
Rebase
Replaying your commits on top of the latest code to keep history neat and linear.
Squash
Combining several small commits into one tidy commit.
Merge vs rebase
Merge keeps both histories; rebase rewrites yours to look like one straight line.
Golden rule
Never rebase work that others have already pulled, or you will confuse everyone.
01

Replay commits

Rebase replays your commits on a new base for a linear history. Never rebase shared/public branches others have pulled.

Try it yourself

bash
$git rebase main
Replay your commits on top of the latest main for a clean history.
$git rebase -i HEAD~3
Interactively reword, squash, or reorder the last 3 commits.
$git push --force-with-lease
Force-push safely, refusing if someone else pushed first.
↳ lines explain what each command does — only the commands get copied

Finished this topic?

Mark it done to earn 100 XP and keep your streak alive.