What happens to the commit history during a rebase?

When you run git rebase, the commit history is rewritten, old commits are replaced by new ones, even if the code changes are the same.

This is the most important thing to understand about rebase.

---

#What "the history is rewritten" means

When you run rebase, Git:

1. Takes the commits of your branch
2. Temporarily "removes" them
3. Moves the branch onto a different base commit
4. Creates new commits, reapplying the changes

The old commits stop being part of the branch's history.

---

#Visually

Before rebase:

After rebase:

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

• D' and E' are the new commits
• the hashes changed
• the original D and E are no longer used

---

#What exactly changes

Even if the code is identical, Git treats them as different commits.

---

#Why this is dangerous for shared branches

If a branch is already:

• pushed
• used by other developers

After a rebase:

• you have a different history
• your colleagues have the old one
• Git cannot automatically reconcile them

The result is conflicts and a "broken" history.

---

#How this is phrased at an interview

With git rebase the history is rewritten: commits are recreated with new hashes, which changes the sequence of the history.

And often they add:

That's why rebase should not be done on public branches.

---

#Advantages of this approach

• a tidy, linear history
• git log is easy to read
• convenient before a merge

---

#Short answer (if really brief)

git rebase rewrites the commit history: old commits are replaced by new ones with different hashes.