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

Znasz już podstawy — git add, git commit, git push. To wystarcza do większości codziennej pracy. Problem zaczyna się wtedy, gdy coś pójdzie nie tak albo kiedy zwykłe komendy przestają wystarczać:

• Przypadkowo usuniesz branch z ważnymi zmianami?
• Musisz przenieść jeden commit między branchami?
• Chcesz znaleźć commit, który wprowadził buga?
• Zrobiłeś commit na złym branchu?

W tym artykule nie chodzi o kolekcję egzotycznych flag. Chodzi o zestaw komend, które realnie pomagają ratować zmiany, przenosić pracę między branchami i odzyskiwać kontrolę nad historią.

Krótka odpowiedź: Najważniejsze komendy ratunkowe: git stash (schowaj zmiany), git cherry-pick (przenieś commit), git reflog (odzyskaj "utracone" commity), git reset --soft HEAD~1 (cofnij do staging), git revert (bezpieczne cofnięcie na remote). Złota zasada: nie przepisuj historii, która była już wypchnięta — użyj revert.

1. git stash — schowek na zmiany

Masz niezacommitowane zmiany, ale musisz przełączyć się na inny branch:

# Schowaj zmiany (tylko śledzone pliki!)
git stash
 
# Schowaj też untracked files (nowe pliki bez git add)
git stash -u   # --include-untracked
 
# Schowaj z opisem
git stash push -m "Work in progress: navbar"
 
# Lista schowków
git stash list
 
# Przywróć ostatni stash (usuwa ze stosu)
git stash pop
 
# Przywróć bez usuwania
git stash apply
 
# Przywróć konkretny stash
git stash apply stash@{1}
 
# Usuń stash
git stash drop stash@{0}
 
# Usuń wszystkie stashe
git stash clear

Stash pojedynczych plików

git stash push -m "description" -- path/to/file.js
git stash push --keep-index  # zachowaj staged

git stash jest świetny jako narzędzie awaryjne, ale nie powinien zastępować sensownych commitów. Jeśli stash zaczyna żyć tydzień albo dwa, zwykle lepiej zrobić roboczy commit na branchu.

2. git cherry-pick — przenieś commit

Przenieś konkretny commit z jednego brancha na drugi:

# Znajdź hash commita
git log --oneline feature-branch
 
# Przełącz na docelowy branch
git switch main
 
# Przenieś commit
git cherry-pick abc1234
 
# Przenieś wiele commitów
git cherry-pick abc1234 def5678
 
# Bez automatycznego commita
git cherry-pick --no-commit abc1234

Rozwiązywanie konfliktów

git cherry-pick abc1234
# CONFLICT...
git add <resolved-files>
git cherry-pick --continue
# lub przerwij:
git cherry-pick --abort

cherry-pick najlepiej działa do przenoszenia pojedynczych, niezależnych commitów. Jeśli próbujesz w ten sposób kopiować połowę brancha, zwykle znak, że lepszy będzie merge albo rebase.

3. git reflog — historia wszystkiego

Reflog zapisuje każdą zmianę HEAD — nawet usunięte commity!

git reflog
# abc1234 HEAD@{0}: commit: Ostatni commit
# def5678 HEAD@{1}: reset: moving to HEAD~3

Przywróć usunięty commit

# Ups, zrobiłem reset --hard
git reset --hard HEAD~3
 
# Znajdź utracone commity
git reflog
 
# Przywróć!
git reset --hard def5678

Najważniejsze ograniczenie refloga: to historia lokalna, nie zdalna. I nie jest wieczna. Jeśli czekasz z odzyskiwaniem tygodniami albo czyścisz repo, część wpisów może już zniknąć.

Przywróć usunięty branch

git branch -D feature-important  # ups!
 
git reflog
# Znajdź ostatni commit brancha
 
git checkout -b feature-important abc1234

4. git reset vs git revert

git reset — przepisz historię

git reset --soft HEAD~1   # zachowaj w staging
git reset --mixed HEAD~1  # zachowaj w working dir
git reset --hard HEAD~1   # USUŃ zmiany

Używaj gdy: pracujesz lokalnie, przed push.

reset --hard jest skuteczny, ale bezlitosny. Zanim go użyjesz, upewnij się, że naprawdę chcesz porzucić lokalne zmiany albo że masz je w reflogu, stashu lub na innym branchu.

git revert — dodaj commit cofający

git revert abc1234

Używaj gdy: zmiany są już na remote.

5. git bisect — znajdź buggy commit

Binary search przez historię:

git bisect start
git bisect bad              # aktualny jest zły
git bisect good abc1234     # ten był dobry
 
# Git checkoutuje commit w połowie
# Testuj i oznaczaj:
git bisect good  # lub
git bisect bad
 
# Git znajdzie winowajcę
git bisect reset  # zakończ

Automatyczny bisect

git bisect start HEAD abc1234
git bisect run npm test

Przy git bisect run pamiętaj, że komenda testowa powinna zwracać poprawny kod wyjścia: 0 dla "good", niezero dla "bad", a 125 dla commita do pominięcia.

6. git rebase -i — edytuj commity

git rebase -i HEAD~3

Otwiera edytor:

pick abc1234 First commit
pick def5678 Second commit
pick ghi9012 Third commit

# Komendy:
# pick = użyj commit
# reword = zmień message
# squash = połącz z poprzednim
# fixup = połącz, odrzuć message
# drop = usuń commit

Squash — połącz commity

pick abc1234 First commit
squash def5678 Second commit
squash ghi9012 Third commit

Interaktywny rebase to świetne narzędzie do sprzątania lokalnej historii przed wypchnięciem branchu do review. Jeśli commit został już opublikowany i ktoś inny na nim pracuje, rebase zaczyna być ryzykowny.

7. git log — zaawansowane wyszukiwanie

git log --oneline --graph --all
git log --author="Jan"
git log --since="1 week ago"
git log -- path/to/file.js
git log --grep="fix bug"
git log -S "functionName"
git log -p  # z diffem
git log --stat

Szczególnie przydatne są:

• git log -S "string" gdy szukasz, w którym commicie pojawił się lub zniknął konkretny fragment
• git log -- path/to/file gdy chcesz zawęzić historię do jednego pliku
• git log --graph --decorate --oneline --all gdy próbujesz zrozumieć rozjazd branchy

8. git diff — porównywanie

git diff                    # working directory
git diff --staged           # staging area
git diff main..feature      # między branchami
git diff HEAD~1 HEAD        # ostatni commit vs poprzedni
git diff --name-only        # tylko nazwy plików
git diff -w                 # ignoruj whitespace

9. git clean — usuń untracked files

git clean -n    # podgląd (zawsze zacznij od tego!)
git clean -f    # usuń pliki
git clean -fd   # usuń pliki i foldery
git clean -fdx  # też ignorowane — ⚠️ usuwa też .env i pliki z .gitignore!
git clean -i    # interaktywnie (bezpieczniejsze)

git clean czyści tylko pliki nieśledzone, ale nadal potrafi boleć. -fdx usuwa także to, co masz w .gitignore, więc bardzo łatwo skasować lokalne .env, buildy, cache albo dane testowe.

10. git worktree — wiele working directories

git worktree add ../project-feature feature-branch
git worktree list
git worktree remove ../project-feature

worktree jest niedoceniane. Pozwala pracować na kilku branchach jednocześnie bez ciągłego stashowania i checkoutów. To szczególnie wygodne przy review, hotfixach i równoległej pracy nad dwiema funkcjami.

Ratunkowe scenariusze

"Cofnij ostatni commit, chcę go poprawić"

git reset --soft HEAD~1
# Popraw i commitnij ponownie

"Zcommitowałem na złym branchu"

# jeśli commit NIE został jeszcze wypchnięty
git switch -c correct-branch
git switch main
git reset --hard HEAD~1

Jeśli commit został już wypchnięty, nie przepisuj historii w ciemno. Zwykle bezpieczniej zrobić git revert na złym branchu i przenieść zmianę osobnym cherry-pick.

"Chcę zmienić message ostatniego commita"

git commit --amend -m "Nowy message"

"Muszę dodać plik do ostatniego commita"

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

"Wypchnąłem coś złego na remote"

git revert HEAD
git push

"Zrobiłem merge, ale chcę go cofnąć"

git revert -m 1 HEAD  # -m 1 = zachowaj pierwszego rodzica

"Potrzebuję pliku z innego brancha"

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

"Chcę zobaczyć kto napisał tę linię"

git blame path/to/file.js
git blame -L 10,20 file.js  # linie 10-20

FAQ

Jak cofnąć ostatni commit w Git?

Zależy, czy commit był wypchnięty na remote. Lokalnie (nie wypchnięty): git reset --soft HEAD~1 cofnie commit zachowując zmiany w staging area — możesz poprawić i commitnąć ponownie. git reset --mixed HEAD~1 zachowuje zmiany w working directory. Na remote (wypchnięty): git revert HEAD tworzy nowy commit cofający zmiany — bezpieczne, nie przepisuje historii.

Jak odzyskać utracone commity w Git?

Użyj git reflog — zapisuje każdą zmianę HEAD, łącznie z commitami "usuniętymi" przez reset --hard. Znajdź hash commita który chcesz odzyskać, potem git reset --hard <hash> lub git checkout -b recovered-branch <hash>. Ważne: reflog jest lokalny i ma ograniczony czas życia (domyślnie 90 dni) — nie czekaj zbyt długo.

Jaka różnica między git reset a git revert?

git reset przepisuje historię — przesuwa HEAD i usuwa commity z historii. Bezpieczny tylko lokalnie, przed pushowaniem. git revert dodaje nowy commit, który cofa zmiany poprzedniego — historia jest zachowana, a cofnięcie jest widoczne. To poprawna metoda cofania zmian na współdzielonym remote. Zasada: reset lokalnie, revert na remote.

Co to jest git stash i kiedy go używać?

git stash tymczasowo odkłada niezacommitowane zmiany, przywracając clean working directory. Przydatny gdy musisz pilnie przełączyć branch. git stash -u zbiera też nowe untracked pliki. git stash pop przywraca ostatni stash. Używaj jako narzędzie awaryjne, nie jako zastępnik commitów — stash żyjący tygodniami to przepis na ból.

Co to jest git cherry-pick i kiedy go używać?

git cherry-pick <hash> przenosi konkretny commit na aktualny branch, tworząc nowy commit o tej samej zmianie ale innym hashu. Przydatne gdy chcesz przenieść poprawkę buga z feature branch na main bez mergowania całego brancha. Dla pojedynczych, niezależnych commitów to idealne narzędzie. Jeśli próbujesz przenieść połowę historii brancha, rozważ merge lub rebase.

Jak znaleźć commit, który wprowadził buga?

Użyj git bisect — przeprowadza binary search przez historię commitów. git bisect start, git bisect bad (aktualny jest zły), git bisect good <hash> (ten był dobry). Git checkoutuje commit w połowie zakresu — testujesz i oznaczasz git bisect good/bad. Po znalezieniu winowajcy: git bisect reset. Możesz też zautomatyzować: git bisect run npm test.

Jak pracować na wielu branchach jednocześnie?

git worktree add ../project-hotfix hotfix-branch tworzy osobny working directory dla innego brancha — bez stashowania, bez checkoutu. Możesz jednocześnie pracować na feature branch i pisać hotfix w osobnym folderze, oba wskazują na to samo repozytorium. git worktree list pokazuje aktywne worktree, git worktree remove usuwa gdy skończysz.

Źródła i dokumentacja

• Git Docs: git stash
• Git Docs: git cherry-pick
• Git Docs: git reflog
• Git Docs: git bisect
• Git Docs: git worktree

Podsumowanie — cheat sheet

Złota zasada

Nie zmieniaj historii, która została już wypchnięta i może być używana przez innych. Reset, rebase, amend — głównie lokalnie. Na współdzielonym remote zwykle bezpieczniejszy jest revert.

Git jest potężny, ale z mocą przychodzi odpowiedzialność. Zawsze możesz sprawdzić git reflog — tam jest wszystko.

Potrzebujesz uporządkować podstawy Git? Zacznij od workflow: clone albo init, potem add, commit, pull, push i dopiero na tym buduj bardziej zaawansowane komendy ratunkowe.