Cherry-pick — co to jest, mechanizm i zastosowanie w Git

Co to jest Cherry-pick?

Cherry-pick — to polecenie Git, które kopiuje zmiany z określonego commita i stosuje je jako nowy commit w bieżącej gałęzi. Nazwa pochodzi od metafory „wybierania wiśni”: programista wybiera tylko te commity, które są potrzebne, ignorując pozostałe.

W przeciwieństwie do Merge, cherry-pick nie tworzy merge commita i nie wymaga pełnego scalania gałęzi. W przeciwieństwie do Rebase, cherry-pick nie przenosi sekwencji commitów — tylko wskazane. To czyni cherry-pick idealnym narzędziem do precyzyjnego przenoszenia poprawek.

Według danych Atlassian, 2025, cherry-pick jest używany w 47% zespołów pracujących jednocześnie z kilkoma gałęziami wydań. Cherry-pick jest szczególnie poszukiwany w programowaniu mobilnym, gdzie jednocześnie obsługiwanych jest kilka wersji aplikacji (wydania LTS) i wymagane jest przenoszenie poprawek między nimi.

Mechanizm przenoszenia

Podczas wykonywania cherry-pick Git oblicza diff między wskazanym commitem a jego rodzicem, a następnie stosuje ten diff do bieżącej gałęzi. Jeśli zmiany zostały zastosowane bez konfliktu — Git tworzy nowy commit z tą samą wiadomością, ale nowym SHA. Jeśli wystąpi konflikt — cherry-pick jest wstrzymywany do ręcznego rozwiązania.

Jak działa Cherry-pick

Składnia cherry-pick jest prosta: podaj hash commita, który chcesz przenieść. Git skopiuje zmiany do bieżącej gałęzi jako nowy commit. Obsługiwane jest przenoszenie kilku commitów naraz oraz całych zakresów.

# Przenoszenie jednego commita do bieżącej gałęzi
git cherry-pick a1b2c3d4

# Przenoszenie kilku commitów
git cherry-pick a1b2c3d4 e5f6g7h8

# Przenoszenie zakresu commitów (od a1b2 do f9e8, nie włączając a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Po wykonaniu cherry-pick bieżąca gałąź otrzymuje nowy commit ze zmianami z oryginalnego. Wiadomość commita domyślnie jest kopiowana z oryginalnego, ale może być zmieniona za pomocą flagi -n (nie twórz commita) lub --edit (edytuj wiadomość).

Przykład przenoszenia poprawki

Rozważmy typowy scenariusz: w develop znaleziono i naprawiono krytyczny błąd, który występuje również w gałęzi wydania release/v2.0. Należy przenieść tylko tę poprawkę, bez scalania całego developa z gałęzią wydania.

# Znajdź hash commita z poprawką w develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Przełącz się na gałąź wydania
git checkout release/v2.0

# Zastosuj poprawkę
git cherry-pick a1b2c3d4

# Jeśli konflikt — rozwiąż i kontynuuj
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Flaga -x dodaje do wiadomości commita odniesienie do oryginalnego SHA: „(cherry picked from commit a1b2c3d4)”. Ułatwia to śledzenie, skąd został przeniesiony commit. Zaleca się używanie -x we wszystkich scenariuszach, z wyjątkiem tymczasowych szkiców.

Praca z konfliktami

W przypadku konfliktu cherry-pick zachowuje się jak merge: Git zatrzymuje się i oznacza pliki z konfliktem. Programista rozwiązuje konflikt, wykonuje git add, a następnie git cherry-pick --continue. Aby anulować — git cherry-pick --abort. Flaga --strategy pozwala określić strategię scalania (na przykład recursive z opcjami).

# Rozwiązywanie konfliktu przy cherry-pick
# Git pokazuje pliki z konfliktem
git status

# Rozwiąż ręcznie, następnie:
git add allowed_file.kt
git cherry-pick --continue

# Lub anuluj cherry-pick:
git cherry-pick --abort

Kiedy stosować Cherry-pick

Cherry-pick jest optymalny w scenariuszach, gdzie wymagane jest precyzyjne przenoszenie zmian bez scalania całych gałęzi. Rozważmy pięć głównych przypadków, w których cherry-pick staje się najlepszym wyborem.

• Przenoszenie hotfixa — poprawka znaleziona w develop, ale należy zastosować ją w gałęzi wydania (release/v2.0). Cherry-pick przenosi tylko commit poprawki, nie naruszając niedokończonych funkcji z develop
• Backport do starych wersji — poprawka dla bieżącej wersji musi zostać przeniesiona do wydania LTS. Zamiast scalać całą bieżącą bazę kodu, cherry-pick wybiera tylko potrzebne commity
• Cofnięcie commita w innej gałęzi — jeśli commit został wykonany w niewłaściwej gałęzi, cherry-pick przenosi go do właściwej, a oryginalny commit jest cofany
• Przenoszenie dokumentacji — zmiany w README lub plikach konfiguracyjnych, które powinny znajdować się we wszystkich gałęziach, wygodnie przenosić przez cherry-pick
• Selektywne stosowanie — z gałęzi prototypu należy wziąć tylko jeden udany commit, nie przenosząc całego prototypu do głównego rozwoju

Dla programowania mobilnego cherry-pick jest krytycznie ważny przy obsłudze kilku wersji aplikacji. Na przykład, jeśli błąd został znaleziony w wersji 3.2 już wydanej w Google Play, a develop zawiera kod dla wersji 4.0 — cherry-pick pozwala przenieść poprawkę do gałęzi v3.x bez scalania wszystkich breaking changes. Jest to szczególnie istotne w projektach, gdzie jednocześnie obsługiwane są dwie lub więcej głównych wersji z różnymi API i zależnościami.

Przykład z praktyki: w aplikacji mobilnej wykryto crash podczas autoryzacji przez Google Sign-In na Androidzie 12. Poprawka została wprowadzona w develop i przeszła review. Jednak bieżąca gałąź wydania v2.5 jest już na etapie beta-testów. Cherry-pick commita poprawki z develop do release/v2.5 pozwala włączyć poprawkę do najbliższego wydania, nie przenosząc pozostałych zmian, które nie są jeszcze gotowe do wypuszczenia.

Przy używaniu cherry-pick w projektach mobilnych ważne jest uwzględnienie zależności: jeśli poprawka dotyczy plików, które zostały zmienione w develop po punkcie rozgałęzienia gałęzi wydania, cherry-pick może przynieść niekompletny zestaw zmian. W takich przypadkach należy sprawdzić, czy wszystkie powiązane zmiany zostały również przeniesione, w przeciwnym razie aplikacja może się nie zbudować lub działać nieprawidłowo. Zawsze sprawdzaj kompilację po cherry-pick przed wypchnięciem zmian do wspólnej gałęzi.

Cherry-pick vs Merge vs Rebase

Trzy główne narzędzia integracji zmian w Git — merge, rebase i cherry-pick — rozwiązują różne zadania. Wybór zależy od tego, jaki zakres zmian należy przenieść i jak powinna wyglądać historia.

Merge — gdy trzeba scalić dwie gałęzie w całości i zachować informację o rozgałęzieniach. Rebase — gdy trzeba zaktualizować osobistą gałąź do aktualnego stanu z czystą historią. Cherry-pick — gdy potrzebny jest tylko jeden commit lub kilka wybranych commitów.

W praktyce te narzędzia są kombinowane: funkcja jest rozwijana z okresowym rebase na develop, następnie scalana przez --no-ff merge, a w razie potrzeby przeniesienia poprawki do innej gałęzi używany jest cherry-pick. Każde narzędzie rozwiązuje swoje zadanie na swoim etapie.

Ryzyka i ograniczenia Cherry-pick

Cherry-pick — użyteczne, ale potencjalnie niebezpieczne narzędzie przy nieprawidłowym lub nadmiernym używaniu. Główne ryzyka związane są z duplikowaniem commitów, utratą kontekstu i konfliktami przy późniejszych scalaniach.

• Duplikowanie commitów — jeśli ten sam commit później trafi do gałęzi przez merge, Git utworzy drugi, identyczny pod względem zmian commit. Zanieczyszcza to historię i utrudnia git bisect
• Utrata kontekstu — cherry-pick przenosi diff, ale nie przenosi informacji o rodzicielskich commitach i zależnościach. Jeśli cherry-pick zastosował commit A bez commita B, od którego A był zależny, mogą wystąpić błędy logiczne
• Konflikty przy merge — po cherry-pick przy pełnym scalaniu gałęzi Git może zobaczyć te same zmiany dwukrotnie i utworzyć konflikty, których można było uniknąć przy zwykłym mergu
• Brak powiązania — bez flagi -x nie można zrozumieć, że commit został przeniesiony z innej gałęzi. Podczas szukania źródła zmiany programista może spędzić godziny na ustalaniu pochodzenia commita

Zalecenia dotyczące minimalizacji ryzyk: zawsze używaj flagi -x do wskazania oryginalnego SHA, dokumentuj powód cherry-pick w wiadomości commita, i jeśli to możliwe, używaj merge zamiast cherry-pick, gdy pozwala na to kontekst. Jeśli cherry-picków jest dużo — rozważ restrukturyzację gałęzi.

Automatyzacja sprawdzeń przy Cherry-pick

Pipeline'y CI powinny uwzględniać cherry-pick jako osobny scenariusz. Zaleca się skonfigurowanie automatycznego sprawdzania: przy tworzeniu cherry-pick commita CI sprawdza, czy zmodyfikowane pliki odpowiadają oczekiwanemu zestawowi, i uruchamia testy dla dotkniętych modułów. Zmniejsza to ryzyko regresji przy precyzyjnym przenoszeniu zmian między gałęziami.