git rebase (Conceptual)

The Hook (The "Byte-Sized" Intro)

Imagine you wrote 5 commits on a feature branch. Meanwhile, main moved forward. git merge would create a tangled web. git rebase takes your 5 commits, lifts them off, and replays them one-by-one on top of the latest main — as if you started your work just now. The result? A perfectly linear history. No merge commit. No branch spaghetti.

📖 What is git rebase (Conceptual)?

Rebase moves (replays) a series of commits onto a new base commit. Instead of merging two divergent histories together, it rewrites your commits so they appear to have been written on top of the latest base.

Conceptual Clarity

Before rebase:

main:    A ─ B ─ C ─ D
              \
feature:       E ─ F ─ G

After git rebase main (from feature):

main:    A ─ B ─ C ─ D
                      \
feature:               E' ─ F' ─ G'

The commits E', F', G' have the same changes as E, F, G but new hashes — they're technically new commits.

What rebase does internally:

Finds the common ancestor of the two branches
Saves the diffs of each commit on your branch
Moves the branch pointer to the new base
Replays each saved diff one by one

Real-Life Analogy

Rebase is like rewriting your essay so it references the latest textbook edition instead of the old one. The content is essentially the same, but it's built on top of the most current source material.

Visual Architecture

flowchart LR subgraph BEFORE["Before Rebase"] B_M["main: A─B─C─D"] B_F["feature: E─F─G"] end subgraph AFTER["After Rebase"] A_M["main: A─B─C─D"] A_F["feature: D─E'─F'─G'"] end BEFORE -->|"git rebase main"| AFTER style BEFORE fill:#1a1a2e,stroke:#e94560,color:#e94560 style AFTER fill:#1b2d1b,stroke:#53d8fb,color:#53d8fb

Why It Matters

Linear history: git log becomes a clean, readable story instead of a merge maze.
Cleaner PRs: A rebased branch shows only your changes, not merge noise.
Easier bisect: Linear history makes git bisect faster and more reliable.
Understanding: Rebase is a core concept — interviewers test it frequently.

Code

bash

# ─── Basic rebase: replay feature commits onto main ───
git switch feature/login
git rebase main
# Your commits are now on top of main's latest

# ─── If conflicts occur during rebase ───
# Git pauses at the conflicting commit
git add resolved-file.js
git rebase --continue
# Repeat for each conflicting commit

# ─── Abort a rebase if things go wrong ───
git rebase --abort
# Everything returns to pre-rebase state

# ─── After rebase: force-push (history changed) ───
git push --force-with-lease

# ─── Rebase onto a specific commit ───
git rebase abc1234

Rebase vs Merge

Aspect	Merge	Rebase
History shape	Branched (merge commits)	Linear (no merge commits)
Original commits	Preserved	Replaced with new copies
Safe for shared branches?	✅ Always	❌ Only for personal branches
Conflict resolution	Once per merge	Once per replayed commit
`git log` appearance	Shows branch topology	Clean, straight line

Key Takeaways

Rebase replays your commits on top of a new base — creating linear history.
Commits get new hashes after rebase (they're technically new commits).
Never rebase shared/public branches — only rebase your own feature branches.
Use --force-with-lease to push after rebasing.

Interview Prep

Q: What does git rebase do conceptually? A: It takes the commits from your current branch, temporarily removes them, moves the branch pointer to the new base commit, and replays each commit one by one on top of it. The result is a linear history as if the work happened sequentially.
Q: Why do commits get new hashes after a rebase? A: Because a commit's hash is derived from its content, parent, timestamp, and metadata. When rebase replays a commit on a new base, the parent changes, which changes the hash — even though the code changes are identical.
Q: When should you NOT use rebase? A: Never rebase commits that have been pushed to a shared branch that others are working on. Rebase rewrites commit hashes, which causes everyone else's clone to diverge from the remote, creating confusion and potential data loss.