git cherry-pick - Learning Zone

git cherry-pick bierze konkretny commit (albo kilka) z dowolnego miejsca w repozytorium i nakłada jego zmiany na gałąź, na której właśnie stoisz, tworząc nowy commit z tą samą treścią zmian. Przydaje się, gdy chcesz przenieść jedną poprawkę z jednej gałęzi na drugą, ale nie chcesz scalać całej gałęzi ani robić rebase’a. Klasyczny scenariusz: hotfix wylądował na develop, a Ty potrzebujesz go też na main — wybierasz ten jeden commit i tyle.

Składnia i najważniejsze opcje

Podstawowa forma: git cherry-pick ...

-e, --edit — pozwala zmienić komunikat commita przed jego utworzeniem.
-n, --no-commit — nakłada zmiany do indeksu i drzewa roboczego, ale nie tworzy commita (sam decydujesz, kiedy zatwierdzić).
-x — dopisuje do komunikatu linijkę (cherry picked from commit …) z oryginalnym hashem, co ułatwia śledzenie pochodzenia.
-s, --signoff — dodaje na końcu komunikatu linię Signed-off-by.
-m , --mainline — wymagane przy cherry-picku commita merge: wskazujesz, który rodzic ma być „głównym” punktem odniesienia.
--continue — wznawia operację po ręcznym rozwiązaniu konfliktów.
--abort — przerywa operację i wraca do stanu sprzed cherry-picka.
--skip — pomija bieżący commit i przechodzi do następnego (gdy podałeś ich kilka).

Przykłady użycia

git cherry-pick a1b2c3d — nakłada pojedynczy commit o tym hashu na bieżącą gałąź i od razu go zatwierdza.
git cherry-pick a1b2c3d e4f5g6h — przenosi dwa wskazane commity, jeden po drugim, w podanej kolejności.
git cherry-pick a1b2c3d^..e4f5g6h — przenosi cały zakres commitów od a1b2c3d do e4f5g6h włącznie.
git cherry-pick -n a1b2c3d — wrzuca zmiany do staging bez tworzenia commita, żebyś mógł je jeszcze poprawić lub połączyć z innymi.
git cherry-pick -x a1b2c3d — przenosi commit i zapisuje w opisie skąd pochodzi (przydatne przy backportach do gałęzi wydaniowych).

Częste błędy i pułapki

Najczęstsza wpadka to konflikty. Cherry-pick nakłada zmiany na inny kontekst niż ten, w którym powstały, więc Git może nie wiedzieć, jak je dopasować. Wtedy operacja się zatrzymuje: rozwiązujesz konflikty, robisz git add na poprawionych plikach i wołasz git cherry-pick --continue. Jak się pogubisz, ratunkiem jest --abort.

Druga pułapka: cherry-pick tworzy nowy commit z nowym hashem, nawet jeśli treść zmian jest identyczna. Jeśli później scalisz gałąź, z której pochodził, możesz mieć ten sam diff w dwóch miejscach historii — bywa to mylące, choć Git zwykle radzi sobie z tym przy merge’u.

Trzecia: próba cherry-picka commita merge bez podania -m skończy się błędem — Git nie wie, względem którego rodzica liczyć zmiany. Pamiętaj też, że nadużywanie cherry-picka zamiast normalnego merge/rebase szybko rozjeżdża historię gałęzi.

Powiązane komendy: git merge, git rebase, git revert, git log, git reset.