git rebase: Replaying Commits on a New Base, Interactive Rebase Introduced

Module 4 introduced `git pull --rebase` as a way to keep history linear when syncing with a remote. This lesson generalizes that same underlying mechanism — rebasing — to its full, standalone form: `git rebase`, usable to replay any branch's commits onto any new base commit, not just during a pull. Understanding this general mechanism in depth is the foundation for the entire rest of this module.

Learning Objectives

Explain precisely what git rebase does at a mechanical level.
Rebase a feature branch onto an updated main branch.
Understand why rebased commits receive new hashes.
Recognize rebase conflicts and how they differ from merge conflicts in the resolution flow.

Key Terms to Know Before Learning git rebase

git rebase <base>: Replays the commits unique to your current branch, one by one, onto the tip of the specified base, creating new commits with new hashes.
Base commit: The commit a rebase operation moves your branch's commits to begin from — typically the latest commit on a branch like main.
Replaying: The process of reapplying each commit's changes, in order, onto a new starting point, as if they had been written there originally.
Rebase conflict: A conflict that occurs while replaying a specific commit during a rebase, resolved one commit at a time rather than all at once.

How git rebase Actually Works Under the Hood

Recall the mechanical explanation from Module 4's `git pull --rebase` lesson: rebasing doesn't move your original commits — it creates **brand new commits** with the same changes and messages, but different parent commits (and therefore different hashes). `git rebase` generalizes this beyond just syncing with a remote, letting you replay your current branch's unique commits onto **any** base commit you specify:

```
git switch feature/dark-mode
git rebase main
```

Mechanically, here's exactly what happens: Git identifies every commit that exists on `feature/dark-mode` but not on `main` (i.e., the commits unique to your feature branch since it diverged). It then temporarily sets these aside, moves your branch's starting point to match the current tip of `main`, and **replays** each of those unique commits, one at a time, in their original order, on top of that new position — each replay creating a new commit object with the same change content and message as the original, but a new parent (and therefore a new hash).

The practical result: your feature branch's history now looks as if you had started your work *after* all of `main`'s latest commits, rather than showing the actual, messier chronological reality of when you actually diverged and continued working in parallel. This produces the same clean, linear history benefit discussed for `pull --rebase`, but now available as a general-purpose tool for any branch, at any time, not just during a sync.

Just like a merge, a rebase can encounter conflicts — but the resolution *flow* is meaningfully different. A merge conflict (Module 3) happens once, reconciling all divergent changes together in a single operation. A **rebase conflict** happens **once per commit being replayed** — if commit 3 of 5 being replayed conflicts, you resolve just that one conflict, then continue the rebase (`git rebase --continue`), and the process moves on to replay commit 4, which might also conflict independently. This means a rebase with many commits touching overlapping content can require resolving several separate conflicts in sequence, one at a time, rather than one larger, combined conflict as a merge would produce.

This lesson deliberately covers only the basic, non-interactive form of rebase (`git rebase <base>`), replaying commits as-is onto a new base — the next lesson introduces **interactive rebase**, which adds the ability to also edit, reorder, combine, or remove commits during the replay process, a significantly more powerful (and more commonly used in practice) variant of the same underlying mechanism.

git rebase: Visual Walkthrough of Replaying Commits

Draw a before/after diagram. BEFORE: main at commit M2 (having advanced past the point feature/dark-mode originally branched from, M1). feature/dark-mode still branching from M1, with its own commits C1-C2-C3. AFTER 'git rebase main' (run from feature/dark-mode): show C1-C2-C3 REMOVED from their original position, and NEW commits C1'-C2'-C3' (different hashes, same content) placed directly after M2 in a single straight line. Caption: 'feature/dark-mode now looks like it started AFTER main's latest work, not from where it actually diverged.'

git rebase vs git merge: Quick Reference Table

Aspect	git merge	git rebase
Resulting history shape	Can include a merge commit, preserving actual chronology	Linear — branch appears to start after the base's latest commit
Original commit hashes preserved?	Yes	No — replayed commits get new hashes
Conflict resolution flow	One combined conflict resolution for all divergent changes	One conflict resolution per replayed commit, potentially several in sequence
Safe on already-pushed/shared commits?	Yes — merging never rewrites existing commits	No — only rebase local, not-yet-shared commits (golden rule, next lessons)

git rebase: Command Syntax and Examples

# Rebase a feature branch onto the latest main
git switch feature/dark-mode
git rebase main

# If a conflict occurs while replaying a specific commit:
# CONFLICT (content): Merge conflict in style.css
# (resolve the conflict in that file, exactly as covered in Module 3)
git add style.css
git rebase --continue
# (Git moves on to replay the NEXT commit, which may conflict independently)

# If you decide partway through that this rebase isn't going well:
git rebase --abort
# (safely returns the branch to its exact state before the rebase began)

Breaking Down the git rebase Example

`git rebase main`, run from `feature/dark-mode`, replays that branch's unique commits onto the current tip of `main`. The conflict-handling block demonstrates the per-commit resolution flow: resolving the conflicted file exactly as in a merge, then running `git rebase --continue` (rather than `git commit`) to proceed to replaying the next commit — a detail worth noting, since committing during a rebase conflict resolution uses a different command than a normal commit. `git rebase --abort` demonstrates a valuable safety net: at any point during an in-progress, not-yet-finished rebase, this command cleanly cancels the entire operation and restores the branch to exactly its pre-rebase state, useful if a rebase is producing more conflicts than it's worth resolving.

How git rebase Is Used on Real Engineering Teams

Developers frequently rebase a long-lived feature branch onto the latest main right before opening a pull request, ensuring the PR's diff reflects the current state of the codebase and minimizing the chance of conflicts during eventual merging.
Teams practicing a rebase-heavy workflow (as opposed to frequent merge commits) rely on this exact command as their primary tool for keeping feature branches current with ongoing changes on main.
git rebase --abort is a commonly reached-for safety net among developers experimenting with a rebase that turns out to involve far more conflicts than anticipated, especially on a branch that has diverged significantly.
CI/CD pipelines sometimes require a feature branch to be successfully rebased onto the latest main before allowing a pull request to be merged, specifically to catch integration issues before they reach the shared branch.

git rebase Interview Questions and Answers

Q1. What does git rebase do at a mechanical level?

It identifies the commits unique to your current branch since it diverged from a specified base, temporarily sets them aside, moves your branch to the current tip of that base, and replays each unique commit one by one on top, creating new commit objects with the same content and message but different parent commits and hashes.

Q2. How does conflict resolution differ between a rebase and a merge?

A merge conflict is resolved once, reconciling all divergent changes together in a single operation. A rebase conflict is resolved once per replayed commit — if multiple commits touch overlapping content, you may need to resolve several separate conflicts in sequence, running git rebase --continue after each one to proceed to the next.

Q3. What does git rebase --abort do, and when would you use it?

It safely cancels an in-progress, not-yet-finished rebase and restores the branch to exactly its state before the rebase began. It's useful when a rebase turns out to involve significantly more conflicts than anticipated, letting you cleanly back out rather than resolving every conflict.

git rebase Quiz: Test Your Understanding

1. What happens to the original commit hashes of a branch's unique commits after a rebase?

They remain exactly the same
They are replaced with new hashes, since the commits are recreated with different parents
They are deleted with no replacement
Only the first commit's hash changes

Answer: B. They are replaced with new hashes, since the commits are recreated with different parents

Explanation: Rebasing replays each commit as a new commit object with the same content and message but a different parent, resulting in a different hash than the original commit.

2. How does rebase conflict resolution differ from merge conflict resolution?

They are identical in every way
Rebase resolves one conflict per replayed commit, potentially several in sequence; merge resolves all divergent changes in one combined operation
Rebase never has conflicts
Merge always requires more steps than rebase

Answer: B. Rebase resolves one conflict per replayed commit, potentially several in sequence; merge resolves all divergent changes in one combined operation

Explanation: Because rebase replays commits one at a time, a conflict can occur independently at each replayed commit, requiring git rebase --continue after each resolution, unlike a merge's single combined conflict resolution.

3. What does git rebase --abort do?

Permanently deletes the branch
Cancels an in-progress rebase and restores the branch to its pre-rebase state
Forces the rebase to complete despite conflicts
Pushes the current state to the remote

Answer: B. Cancels an in-progress rebase and restores the branch to its pre-rebase state

Explanation: This command safely backs out of a rebase that hasn't yet completed, returning the branch to exactly how it was before the rebase operation began.

Common git rebase Mistakes Beginners Make

Assuming rebase preserves original commit hashes, leading to confusion when a rebased branch's commits don't match what a collaborator already has.
Forgetting to use git rebase --continue (instead of a normal git commit) after resolving a conflict during an in-progress rebase.
Not knowing about git rebase --abort, and instead trying to manually undo a problematic in-progress rebase.
Rebasing a branch that has already been pushed and shared with others, without understanding the consequences (covered in depth in a later lesson this module).

git rebase: Exam-Ready Quick Notes

git rebase <base>: replays current branch's unique commits onto the base, creating new commits with new hashes.
Resulting history: linear, appears as if work started after the base's latest commit.
Conflict resolution: one conflict per replayed commit; use git rebase --continue after each resolution.
git rebase --abort: safely cancels an in-progress rebase, restoring the pre-rebase state.

git rebase: Key Takeaways

git rebase generalizes the pull --rebase mechanism from Module 4 into a standalone tool for replaying any branch's commits onto any base.
Rebased commits are genuinely new commit objects with new hashes — the original commits aren't moved, they're recreated.
Rebase conflicts are resolved one commit at a time, a meaningfully different flow than a merge's single combined conflict resolution.

Frequently Asked Questions About git rebase

Q1. What does git rebase actually do?

It takes the commits unique to your current branch and replays them, one by one, onto a new base commit you specify — recreating each as a new commit with the same changes and message, but a different parent and hash, producing a clean, linear history.

Q2. Why do rebased commits get new hashes?

Because rebasing doesn't move the original commits — it recreates them as new commit objects with a different parent commit, and since a commit's hash is derived from its full content including its parent, this results in a new hash even though the actual code changes are identical.

Q3. How do I resolve a conflict during a rebase?

Resolve the conflict in the affected file exactly as you would during a merge, stage the resolved file, and then run git rebase --continue (not git commit) to proceed to replaying the next commit, which may present its own separate conflict.

Q4. What should I do if a rebase is going badly, with more conflicts than expected?

Run git rebase --abort, which safely cancels the in-progress rebase and restores your branch to exactly the state it was in before you started, letting you reconsider your approach without any partial, half-finished changes left behind.

Q5. Is git rebase the same as git pull --rebase from Module 4?

They use the same underlying mechanism, but git pull --rebase specifically combines fetching from a remote with rebasing onto the fetched branch. Plain git rebase is the general-purpose version, letting you replay your branch's commits onto any base you choose, not just a freshly fetched remote branch.

Summary

`git rebase <base>` replays the commits unique to your current branch onto a specified base commit, one at a time, in order — creating new commit objects with the same content and message but different parent commits and hashes, since the originals aren't moved but recreated. This produces a clean, linear history, as though the branch's work had started after the base's latest commits rather than showing the messier actual chronology of parallel development. Conflicts during a rebase are resolved one commit at a time (using `git rebase --continue` after each resolution), a meaningfully different flow than a merge's single, combined conflict resolution. `git rebase --abort` provides a safety net, cleanly canceling an in-progress rebase and restoring the branch to its pre-rebase state. This lesson covers the basic form of rebase; the next lesson introduces interactive rebase, which adds the ability to also edit, reorder, or combine commits during the replay.