Historia commitów to dokumentacja projektu – czytają ją inni programiści, git bisect po niej szuka błędów, a git blame tłumaczy decyzje. Dobre wiadomości commitów, umiejętność porządkowania historii przed merge i znajomość cherry-pick oraz bisect to narzędzia, które odróżniają kogoś kto „używa Gita” od kogoś kto nim „zarządza”.
Anatomia dobrego commit message
Konwencja Conventional Commits to de facto standard w projektach open source i dobrze zarządzanych repozytoriach:
typ(zakres): krótkie podsumowanie w trybie rozkazującym (max 72 znaki) Opcjonalny dłuższy opis wyjaśniający CO i DLACZEGO (nie JAK). Zawijaj linie po 72 znakach. Refs: #123 BREAKING CHANGE: opis jeśli API się zmienia
Typy: feat, fix, refactor, docs, test, chore, perf. Zakres jest opcjonalny, ale pomocny: fix(checkout), feat(catalog).
# Złe wiadomości commitów git commit -m "fix" git commit -m "changes" git commit -m "WIP" git commit -m "Magento stuff" # Dobre wiadomości commitów git commit -m "fix(cart): correct tax calculation for virtual products" git commit -m "feat(catalog): add bulk price update via CSV import" git commit -m "refactor(di): replace ObjectManager with constructor injection in OrderService"
rebase -i – porządkowanie historii przed merge
Interaktywny rebase pozwala przepisać historię lokalnych commitów przed wysłaniem na remote. Dostępne operacje: pick (zostaw), squash (połącz z poprzednim), reword (zmień wiadomość), edit (zatrzymaj do edycji), drop (usuń).
# Edytuj ostatnie 3 commity git rebase -i HEAD~3 # Edytor otworzy się z listą: # pick a1b2c3d WIP: fix typo # pick e4f5a6b WIP: more changes # pick 7c8d9e0 WIP: almost done # Zmień na: # pick a1b2c3d WIP: fix typo # squash e4f5a6b WIP: more changes # squash 7c8d9e0 WIP: almost done # Git połączy 3 commity w 1 i otworzy edytor wiadomości # Zmień wiadomość na: # feat(export): add product export service with CSV support
Ważna zasada: nigdy nie rób rebase na commitach które zostały już wypchnięte na shared branch (main, develop). Rebase przepisuje SHA – inne osoby będą miały konflikty historii.
cherry-pick – przenoś pojedyncze commity
# Przenieś konkretny commit na aktualny branch git cherry-pick a3d5e2f # Przenieś zakres commitów git cherry-pick a3d5e2f..f1a2b3c # Cherry-pick bez automatycznego commita (do edycji) git cherry-pick -n a3d5e2f # Typowy use case: hotfix na main, potem cherry-pick na develop git checkout main git cherry-pick hotfix-sha git checkout develop git cherry-pick hotfix-sha
bisect – binarny search po historii
Bisect to binarny search po historii commitów. Idealny gdy wiesz że „kiedyś działało, teraz nie działa” i masz setki commitów między tymi punktami.
# Uruchom bisect git bisect start # Oznacz aktualny commit jako zły git bisect bad # Oznacz ostatni znany dobry commit git bisect good v2.4.6 # Git wybierze commit do przetestowania (bisection) # Testuj, potem oznacz wynik: git bisect good # lub git bisect bad # Git zawęzi zakres o połowę po każdym kroku # Przy 100 commitach potrzebujesz max 7 kroków (log2(100)) # Automatyczny bisect ze skryptem testowym git bisect run php bin/magento catalog:reindex 2>&1 | grep -q "error" && exit 1 || exit 0 # Zakończ bisect git bisect reset
Przydatne opcje git log
# Graficzny widok historii git log --oneline --graph --all # Commity dotykające konkretnego pliku git log --follow -p -- src/Model/OrderService.php # Szukaj w wiadomościach commitów git log --grep="fix(cart)" # Commity konkretnego autora w zakresie dat git log --author="Henryk" --after="2026-01-01" --oneline # Pokaż co zmieniło się w commicie git show --stat HEAD
Podsumowanie
Dobra historia commitów to inwestycja – w debugowanie, code review i dokumentację. Conventional Commits dają czytelną strukturę. Rebase -i pozwala wyczyścić „WIP” przed merge. Cherry-pick przenosi pojedyncze zmiany między branchami. Bisect zmienia wielogodzinne szukanie regresji w kilkuminutowy proces. Następny wpis: branching i merge – strategie, kiedy fast-forward, kiedy merge commit, kiedy rebase.
