What does git rebase do to history?

git rebase changes the commit history, rewriting it as if the commits had been made at a different point in history.

Simply put: rebase moves commits and recreates them, making the history more linear.

---

#What exactly happens during git rebase

Imagine this situation:

You are on feature and run:

Git:

1. temporarily "removes" commits D and E
2. moves the feature pointer to C
3. creates new commits D' and E' on top of C

Result:

A---B---C---D'---E' (feature)

D' and E' are new commits with new hashes, even though the changes are the same.

---

#How this affects history

git rebase:

• rewrites commits
• changes their hashes
• makes the history straight and readable
• removes unnecessary merge commits

---

#Why this matters for an interview

The key phrase:

git rebase does not literally move commits - it recreates them.

This shows understanding, not memorization.

---

#Interactive rebase (git rebase -i)

With interactive mode you can:

• combine commits (squash)
• change messages (reword)
• delete commits
• reorder commits

This is a classic "middle+/senior" level question.

---

#The main rule (must be mentioned)

You must not rebase public commits.

The interview phrasing:

Rebase is safe only for local or not-yet-published branches.

---

#rebase vs merge (very briefly)

• merge keeps the history as it is
• rebase rewrites the history

---

#Short answer for an interview

git rebase rewrites the history by recreating commits on top of a different point in history, which changes their hashes and makes the history linear.

---

#A frequent candidate mistake

Wrong: "rebase just moves the branch" Correct: it recreates the commits, it does not move them.