Git w praktyce: 10 komend, które uratują Ci życie

Ten artykuł nie jest listą egzotycznych flag do zapamiętania na wszelki wypadek, ale bardziej praktyczny zestaw komend Git, które warto znać, gdy repozytorium przestaje zachowywać się jak spokojna sekwencja pull -> commit -> push.

1. git stash: tymczasowy schowek na zmiany

git stash odkłada niezacommitowane zmiany i przywraca czysty working directory. To przydatna opcja, gdy musisz szybko przełączyć branch, zrobić hotfix albo pobrać zmiany z remote bez mieszania ich z aktualną pracą.

# Schowaj zmiany w śledzonych plikach
git stash
 
# Schowaj także nowe, nieśledzone pliki
git stash -u
 
# Schowaj zmiany z opisem
git stash push -m "Work in progress: navbar"
 
# Zobacz listę stashy
git stash list
 
# Przywróć ostatni stash i usuń go ze stosu
git stash pop
 
# Przywróć stash bez usuwania go ze stosu
git stash apply
 
# Przywróć konkretny stash
git stash apply stash@{1}

Jeżeli chcesz odłożyć tylko wybrane pliki, podaj ścieżkę na końcu:

git stash push -m "Tylko formularz kontaktowy" -- src/components/ContactForm.tsx

stash jest wygodny, ale łatwo zamienić go w mały śmietnik, poneiważ jeśli praca ma potrwać dłużej niż kilka godzin, zwykle lepszy będzie mały commit roboczy na osobnym branchu.

2. git cherry-pick: przenieś konkretny commit

git cherry-pick kopiuje zmianę z wybranego commita na aktualny branch i nie przenosi całej historii brancha, ale tworzy nowy commit z tym samym diffem.

# Znajdź hash commita na branchu źródłowym
git log --oneline feature-branch
 
# Przełącz się na branch docelowy
git switch main
 
# Przenieś jeden commit
git cherry-pick abc1234
 
# Przenieś kilka commitów
git cherry-pick abc1234 def5678
 
# Nałóż zmianę bez automatycznego commita
git cherry-pick --no-commit abc1234

Gdy pojawi się konflikt, Git zatrzyma operację i poczeka na decyzję:

git cherry-pick abc1234
 
# Rozwiąż konflikty w plikach
git add <resolved-files>
git cherry-pick --continue
 
# Albo wycofaj całą operację
git cherry-pick --abort

cherry-pick najlepiej działa dla małych, niezależnych commitów: poprawki buga, drobnej zmiany konfiguracyjnej, jednego refaktoru. Jeśli przenosisz w ten sposób połowę brancha, prawdopodobnie lepszy będzie merge albo rebase.

3. git reflog: lokalna czarna skrzynka

Wskaźnik HEADHEAD to wskaźnik pokazujący aktualny commit, na którym pracujesz. Zwykle wskazuje ostatni commit bieżącego brancha. zmienia się przy commitach, resetach, przełączeniach branchy i rebase. git reflog zapisuje te ruchy lokalnie, dlatego często pozwala odzyskać commity, które zniknęły z normalnego git log.

git reflog
 
# Przykładowy wynik:
# abc1234 HEAD@{0}: commit: Popraw walidację formularza
# def5678 HEAD@{1}: reset: moving to HEAD~3
# 91ab2cd HEAD@{2}: checkout: moving from main to feature/login

Typowy scenariusz: robisz reset --hard, orientujesz się, że to był błąd, a potem szukasz poprzedniego stanu w reflogu.

# Błędna operacja
git reset --hard HEAD~3
 
# Szukasz utraconego commita
git reflog
 
# Bezpieczniej najpierw utworzyć branch ratunkowy
git switch -c recovered-work def5678

Reflog pomaga też przy usuniętym branchu:

git branch -D feature-important
 
git reflog
 
# Po znalezieniu ostatniego commita brancha:
git switch -c feature-important abc1234

4. git reset i git revert: dwa różne sposoby cofania

git reset przesuwa aktualny branch na inny commit i w zależności od trybu może zostawić zmiany w staging area, w working directory albo usunąć je z plików roboczych.

git reset --soft HEAD~1
git reset --mixed HEAD~1
git reset --hard HEAD~1

Najprostsze rozróżnienie wygląda tak:

git revert nie przepisuje historii. Dodaje nowy commit, który odwraca konkretną zmianę:

git revert abc1234

Jeśli chcesz cofnąć zmianę, która trafiła już na branch używany przez zespół albo CI/CD, zacznij od revert. O pracy z automatyzacją po stronie repozytorium więcej piszę w artykule o CI/CD dla Next.js.

5. git bisect: znajdź commit, który zepsuł projekt

git bisect prowadzi Cię przez historię metodą wyszukiwania binarnego. Zamiast ręcznie sprawdzać 40 commitów po kolei, oznaczasz znany dobry i znany zły punkt, a Git sam wybiera kolejne commity do testowania.

git bisect start
git bisect bad
git bisect good abc1234
 
# Git przełączy repozytorium na commit w środku zakresu.
# Testujesz aplikację i oznaczasz wynik:
git bisect good
# albo:
git bisect bad
 
# Po znalezieniu winnego commita wracasz do normalnej pracy:
git bisect reset

Jeśli masz test, który jednoznacznie wykrywa problem, możesz zautomatyzować proces:

git bisect start HEAD abc1234
git bisect run npm test

Komenda uruchamiana przez git bisect run musi zwracać poprawny kod wyjścia: 0 dla commita dobrego, niezerowy kod dla commita złego oraz 125, jeśli dany commit trzeba pominąć.

6. git rebase -i: uporządkuj lokalną historię

Interaktywny rebase pozwala zmieniać kolejność commitów, poprawiać opisy, łączyć małe commity i usuwać niepotrzebne zmiany przed review.

git rebase -i HEAD~3

Git otworzy edytor z listą commitów:

pick abc1234 Add login form
pick def5678 Fix typo
pick ghi9012 Add validation
 
# pick = użyj commit
# reword = zmień opis commita
# squash = połącz z poprzednim i edytuj opis
# fixup = połącz z poprzednim i odrzuć opis
# drop = usuń commit

Typowe sprzątanie wygląda tak:

pick abc1234 Add login form
fixup def5678 Fix typo
squash ghi9012 Add validation

Interaktywny rebase ma największy sens przed wypchnięciem brancha albo przed otwarciem pull requesta. Gdy commit jest już używany przez inne osoby, rebase zaczyna generować koszt synchronizacji.

7. git log: szukaj w historii z precyzją

git log jest bardziej elastyczny niż prosta lista commitów, ponieważ pozwala zawężać historię po autorze, czasie, pliku, opisie albo nawet po fragmencie kodu.

git log --oneline --graph --decorate --all
git log --author="Jan"
git log --since="1 week ago"
git log -- path/to/file.ts
git log --grep="fix validation"
git log -S "validateEmail"
git log -p
git log --stat

Najbardziej praktyczne warianty:

• git log --graph --decorate --oneline --all pokazuje rozjazd branchy w czytelnej formie.
• git log -- path/to/file.ts zawęża historię do jednego pliku.
• git log -S "nazwaFunkcji" pokazuje commity, w których dany fragment pojawił się albo zniknął.
• git log -p pokazuje diff każdego commita.

Jeśli debugujesz zmianę zachowania aplikacji, połącz git log -S z testami i narzędziami diagnostycznymi właściwymi dla aplikacji.

8. git diff: zobacz, co naprawdę się zmieniło

git diff pokazuje różnice między working directory, staging area, commitami i branchami. To komenda, którą warto uruchamiać przed commitem częściej niż po fakcie.

git diff
git diff --staged
git diff main..feature/login
git diff HEAD~1 HEAD
git diff --name-only
git diff -w

Najczęstszy workflow przed commitem:

git status --short
git diff
git diff --staged

git diff chroni przed przypadkowym dorzuceniem debug logów, lokalnych zmian konfiguracyjnych albo fragmentu pracy z innego zadania. To szczególnie ważne, gdy pracujesz na dużym branchu i staging robisz partiami.

9. git clean: usuń nieśledzone pliki

git clean usuwa pliki, których Git nie śledzi. To przydatne po eksperymentach, buildach, generowanych plikach albo zmianach zależności, ale jest też jedną z bardziej ryzykownych komend z tej listy.

git clean -n
git clean -f
git clean -fd
git clean -fdx
git clean -i

Różnice są istotne:

Jeśli nie masz pewności, użyj git clean -i. Tryb interaktywny jest wolniejszy, ale daje dodatkową kontrolę nad tym, co faktycznie zniknie.

10. git worktree: kilka branchy bez ciągłego przełączania

git worktree pozwala mieć kilka katalogów roboczych podpiętych do tego samego repozytorium. Każdy katalog może pracować na innym branchu.

git worktree add ../project-hotfix hotfix/payment-error
git worktree list
git worktree remove ../project-hotfix

To rozwiązuje typowy problem. Wyobraź sobie sytuacje, że jesteś w połowie większej zmiany, a nagle trzeba zrobić review albo hotfix. Bez worktree kończy się to stashowaniem, przełączaniem brancha i późniejszym odtwarzaniem kontekstu. Z worktree otwierasz drugi katalog i pracujesz równolegle.

Ratunkowe scenariusze Git

Poniższe przykłady są skrótem decyzyjnym, ponieważ zakładają, że przed wykonaniem komendy sprawdzasz stan repozytorium przez git status.

Cofnij ostatni lokalny commit, ale zostaw zmiany

git reset --soft HEAD~1

Użyj tego, gdy commit jest lokalny i chcesz poprawić treść commita, dodać brakujący plik albo inaczej podzielić zmiany.

Zcommitowałem zmianę na złym branchu

Jeśli commit nie został wypchnięty:

git switch -c correct-branch
git switch previous-branch
git reset --hard HEAD~1

Jeśli commit trafił już na remote, bezpieczniejszy wariant to git revert na złym branchu i git cherry-pick na właściwym.

Chcę zmienić opis ostatniego commita

git commit --amend -m "Poprawny opis commita"

amend zmienia hash commita. Lokalnie to normalne narzędzie, ale po pushu wymaga ostrożności.

Muszę dodać plik do ostatniego commita

git add forgotten-file.ts
git commit --amend --no-edit

To dobre rozwiązanie, gdy commit nie został jeszcze wypchnięty albo pracujesz na prywatnym branchu.

Wypchnąłem złą zmianę na remote

git revert HEAD
git push

To najczytelniejsza ścieżka na branchach współdzielonych. Historia pokazuje zarówno pierwotną zmianę, jak i commit cofający.

Chcę cofnąć merge commit

git revert -m 1 HEAD

-m 1 oznacza, że jako główną linię historii traktujesz pierwszego rodzica merge commita. Zanim go użyjesz sprawdź merge przez git show HEAD.

Potrzebuję jednego pliku z innego brancha

git restore --source other-branch -- path/to/file.ts

To czytelniejsza, nowocześniejsza alternatywa dla starszych wariantów opartych o git checkout --.

Chcę sprawdzić, kto zmienił konkretną linię

git blame path/to/file.ts
git blame -L 10,20 path/to/file.ts

git blame - nie, nie służy do szukania winnych i najlepiej traktować go jako narzędzie do znalezienia kontekstu: commita, pull requesta, decyzji technicznej albo osoby, którą warto zapytać o szczegóły. Tak, może słowo blame, nie jest najszczęśliwsze w tym kontekście...

Cheat sheet: którą komendę wybrać?

Oto mała i praktyczna ściągawka dla chętnych