Zakomitować — co to jest, zasady formatowania i praca z Git

Czym jest commit w Git

Commit w Git — to obiekt, który przechowuje stan plików projektu w określonym momencie czasu. Każdy commit zawiera snapshot wszystkich śledzonych plików, odniesienie do rodzica i metadane. W przeciwieństwie do innych systemów kontroli wersji, Git używa content-addressable storage — każdy obiekt jest identyfikowany przez hash SHA-1 swojej zawartości.

Gdy programista zakomitował zmiany, Git tworzy commit object, który przechowuje: tree object (struktura plików), parent commit hash, autora, komitera, datę i wiadomość. Ten obiekt jest niezmienny — po utworzeniu commita nie można go modyfikować bez zmiany jego hasha. To właśnie niezmienność gwarantuje integralność historii projektu.

# Przygotuj zmiany i zatwierdź
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Wyświetl szczegóły commita
git log --oneline -3
git show HEAD

# Przygotuj wszystkie zmiany i zatwierdź w jednym kroku
git commit -a -m "Update dependencies to latest versions"

Commity tworzą skierowany graf acykliczny (DAG), gdzie każdy nowy commit odnosi się do poprzedniego. Pozwala to poruszać się po historii, cofać zmiany i analizować ewolucję bazy kodu. Zrozumienie struktury Git DAG — podstawa zaawansowanej pracy z commitami.

Jak poprawnie zakomitować zmiany

Proces commita w Git składa się z dwóch etapów: dodania zmian do staging area (indeksu) i utworzenia commita. Staging area pozwala programiście wybrać, które zmiany wejdą do commita, nawet jeśli w katalogu roboczym zmieniono wiele plików.

Zasada atomowości — kluczowa koncepcja dobrego commita. Każdy commit powinien zawierać jedną logiczną zmianę. Jeśli programista naprawia błąd i refaktoryzuje kod — to dwa różne commity. Atomyczne commity upraszczają code review, wycofywanie zmian i analizę historii.

Przed zakomitowaniem warto sprawdzić: czy w kodzie nie pozostały debugowania wypisy, zakomentowane bloki lub przypadkowe zmiany. Służy do tego komenda git diff --cached, która pokazuje, co dokładnie wejdzie do commita. Dodatkowe sprawdzenie przez git status wyświetla listę plików w staging area.

• Sprawdź zmiany — git diff --cached pokazuje co wejdzie do commita
• Sprawdź jakość — kod powinien przechodzić linter i testy przed commitem
• Napisz wiadomość — zrozumiały opis celu zmiany
• Sprawdź staged — git status potwierdza listę plików

Zasady pisania wiadomości commitów

Wiadomość commita — to dokumentacja zmiany dla przyszłych programistów. Dobra wiadomość odpowiada na pytania: co zostało zmienione i dlaczego. Konwencja Conventional Commits (Angular team, 2016) stała się standardem dla wielu projektów i określa format: typ(obszar): opis.

Dobra wiadomość commita składa się z nagłówka (do 50 znaków) i treści (opcjonalnie, do 72 znaków na linię). Nagłówek pisze się w trybie rozkazującym: „Add“ a nie „Added“ lub „Adds“. Capitalization i kropka na końcu nagłówka nie są stosowane — to międzynarodowa konwencja Git.

Zła wiadomość: „fix things“ lub „update“ — nie niesie informacji. Za miesiąc programista nie będzie w stanie zrozumieć, co dokładnie zostało zmienione i dlaczego. Dobra wiadomość: „fix(payment): handle timeout in stripe callback“ — od razu jasne, gdzie i co zostało naprawione.

Częste błędy przy commitach

Programiści, szczególnie początkujący, często popełniają typowe błędy przy commitach. Najczęstszy — zbyt duży commit, w którym zmieszano dziesiątki zmian. Takiego commita nie da się częściowo cofnąć, a code review staje się udręką.

Drugi najczęstszy błąd — zła wiadomość commita. Wiadomości typu „fix“, „update“, „changes“ lub „wip“ nie dają kontekstu przyszłym programistom. Za pół roku nikt nie będzie pamiętał, co dokładnie zostało naprawione. Zasada jest prosta: wyobraź sobie, że za rok przeglądasz historię i próbujesz znaleźć konkretną zmianę.

Trzeci błąd — commit nieskompilowanego lub niedziałającego kodu. Po commicie kod powinien przynajmniej się kompilować. Niezepsuty build — podstawowe wymaganie dla każdego commita do wspólnej gałęzi. W tym celu przed commitem uruchamia się budowanie i testy.

Czwarty błąd — commit z poufnymi danymi. Klucze API, hasła i tokeny nie powinny trafiać do historii Git. Jeśli sekret został już zakomitowany, nie wystarczy go usunąć w nowym commicie — trzeba usunąć go z całej historii przez git filter-branch lub BFG Repo-Cleaner.

Zaawansowane techniki pracy z commitami

Git udostępnia narzędzia do zarządzania historią commitów. Jednym z najbardziej przydatnych jest git commit --amend, pozwalający uzupełnić ostatni commit nowymi zmianami lub poprawić wiadomość. Jest to wygodne, jeśli programista zapomniał dodać plik lub pomylił się w wiadomości.

# Popraw ostatnią wiadomość commita
git commit --amend -m "fix(auth): correct token validation logic"

# Dodaj pominięty plik do ostatniego commita
git add missed-file.txt
git commit --amend --no-edit

# Interaktywny rebase dla ostatnich 3 commitów
git rebase -i HEAD~3

Interactive rebase — potężne narzędzie do przepisywania historii. Pozwala łączyć commity (squash), zmieniać wiadomości (reword), zmieniać kolejność (reorder) i usuwać commity (drop). Jednak rebase zmienia historię, dlatego stosuje się go tylko do lokalnych commitów, które nie zostały jeszcze wypchnięte do zdalnego repozytorium.

Do cofania commitów istnieją dwa podejścia. git revert tworzy nowy commit, który cofa zmiany poprzedniego — bezpieczny sposób zachowujący historię. git reset usuwa commity z historii — niebezpieczny, jeśli commity zostały już wypchnięte. W programowaniu zespołowym używa się tylko git revert do cofania opublikowanych commitów.