Що відбувається з історією комітів при rebase?

При git rebase історія комітів переписується - старі коміти замінюються новими, навіть якщо зміни в коді такі самі.

Це найголовніше, що потрібно розуміти про rebase.

---

#Що означає «переписується історія»

Коли ти робиш rebase, Git:

1. Бере коміти твоєї гілки
2. Тимчасово «прибирає» їх
3. Переміщує гілку на інший базовий коміт
4. Створює нові коміти, застосовуючи зміни заново

Старі коміти перестають бути частиною історії гілки.

---

#Візуально

До rebase:

Після rebase:

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

• D' і E' - нові коміти
• хеші змінилися
• оригінальні D і E більше не використовуються

---

#Що саме змінюється

Навіть якщо код ідентичний, Git вважає їх різними комітами.

---

#Чому це небезпечно для спільних гілок

Якщо гілка вже:

• запушена
• використовується іншими розробниками

Після rebase:

• у тебе інша історія
• у колег стара
• Git не може автоматично їх сумістити

Результат - конфлікти і «зламана» історія.

---

#Як це формулюють на співбесіді

При git rebase історія переписується: коміти пересоздаються з новими хешами, через що змінюється послідовність історії.

І часто додають:

Тому rebase не можна робити для публічних гілок.

---

#Плюси такого підходу

• акуратна, лінійна історія
• легко читати git log
• зручно перед merge

---

#Коротка відповідь (якщо зовсім коротко)

git rebase переписує історію комітів: старі коміти замінюються новими з іншими хешами.