Jak działa rebase interaktywny?

Question

Accepted Answer

**Rebase interaktywny** (`git rebase -i`) pozwala **przepisywać, zmieniać kolejność, łączyć, edytować lub usuwać commity** — czyszcząc historię commitów przed udostępnieniem. To potężne narzędzie do tworzenia czystej, logicznej historii z bałaganiarskich commitów work-in-progress. ## Rozpoczynanie rebase interaktywnego ```bash git rebase -i HEAD~4 # interactively rebase the last 4 commits git rebase -i # rebase commits after # → opens an editor listing the commits with actions to apply ``` ## Akcje ```text pick abc123 Add login form # keep the commit as-is squash def456 Fix typo # COMBINE into the previous commit (merge messages) fixup ghi789 Fix another typo # combine into previous, DISCARD this message reword jkl012 Add validation # keep the commit but EDIT its message edit mno345 Refactor auth # PAUSE to amend the commit (change content) drop pqr678 Debug logging # DELETE this commit entirely # reorder lines to REORDER commits ``` Edytujesz listę — wybierając akcję dla każdego commita (a zmiana kolejności linii zmienia kolejność commitów) — następnie Git je odpowiednio odtwarza. ## Typowe zastosowania ```text ✓ SQUASH multiple WIP commits into one clean commit ("wip", "fix", "oops" → one good commit) ✓ REWORD bad commit messages ✓ REORDER commits into a logical sequence ✓ DROP unwanted commits (debug code, mistakes) ✓ SPLIT a commit (via edit) into smaller commits → Result: a clean, logical history instead of messy development commits. ``` ## Złota reguła nadal obowiązuje ```text ⚠️ Interactive rebase REWRITES history (new commit hashes): → only do it on LOCAL, UNPUSHED commits — never on shared/public history → typical use: clean up your feature branch BEFORE pushing/opening a PR ``` ## Dlaczego to ważne Zrozumienie rebase interaktywnego jest cenne dla **tworzenia czystej historii commitów**, dlatego jest przydatną praktyczną wiedzą do profesjonalnej pracy z Git. Podczas rozwoju kodu commity są często bałaganiarskie — commity work-in-progress z wiadomościami typu "wip", "fix typo", "oops", debug commity i nielogiczna kolejność — a **rebase interaktywny** pozwala **wyczyścić to przed udostępnieniem**: łączenie wielu bałaganiarskich commitów w czyste logiczne, zmiana treści złych wiadomości, zmiana kolejności commitów na sensowną, usuwanie niechcianych commitów (np. kod debug), i rozdzielanie commitów — transformowanie bałaganiarskiej historii rozwoju w czystą, logiczną, podlegającą przejrzeniu sekwencję. To ma znaczenie, ponieważ czysta historia commitów (jak opisano w dobrych praktykach commitowania) ułatwia przegląd kodu, sprawia że historia jest bardziej zrozumiała, i debugowanie (przez bisect) jest bardziej efektywne — dlatego zdolność do porządkowania przed tym, jak inni zobaczą twoją pracę, jest cechą profesjonalnej praktyki Git. Zrozumienie **akcji** (pick, squash, fixup, reword, edit, drop, i zmiana kolejności) i **typowych zastosowań** (zwłaszcza łączenie WIP commitów, bardzo częsta potrzeba) jest praktyczną umiejętnością. Krytycznie, **złota reguła rebase nadal obowiązuje** — rebase interaktywny przepisuje historię (nowe hasze), dlatego musi być wykonywany tylko na **lokalnych, niepushowanych commitach** (nigdy na wspólnej historii), przy typowym zastosowaniu będącym czyszczeniem gałęzi feature'owej *przed* pushowaniem lub otwarciem pull requesta. Ponieważ czysta, logiczna historia commitów jest cenna dla współpracy i utrzymywalności, a ponieważ rozwój naturalnie produkuje bałaganiarskie commity, które rebase interaktywny może wyczyścić przed udostępnieniem (bezpiecznie, na lokalnych commitach), zrozumienie rebase interaktywnego — akcji, typowych zastosowań takich jak łączenie, i zasady bezpieczeństwa — jest cenną, praktycznie istotną wiedzą Git dla profesjonalnego rozwoju, potężnym narzędziem do prezentowania czystej, przejrzystowalnej historii, która wyróżnia przemyślanych użytkowników Git, regularnie stosowanym do polowania pracy przed udostępnieniem jej zespołowi.