git cherry-pick stosuje konkretny commit z jednej gałęzi na inną — kopiując tylko zmiany z tego commita, bez mergowania całej gałęzi. Jest przydatny do selektywnego stosowania konkretnych zmian, na przykład backportowania poprawki.
# apply a specific commit from another branch onto the current branch
git cherry-pick <commit-hash>
git cherry-pick <commit1> <commit2>
git cherry-pick A..B
Cherry-pick pobiera zmiany z konkretnego commita i stosuje je jako nowy commit na bieżącej gałęzi — selektywnie, bez wprowadzania reszty gałęzi źródłowej.
✓ BACKPORTING a fix — apply a bug fix from main to a release/maintenance branch
(without merging all of main's other changes into the release branch)
✓ Applying a specific commit that's ready, while the rest of its branch isn't
✓ Moving a commit made on the wrong branch to the correct one
✓ Selectively pulling one change from another branch
⚠️ Creates DUPLICATE commits (same changes, different hashes on each branch):
→ can cause confusion/conflicts if branches are later merged (the change appears twice,
though Git often handles it). Prefer merge/rebase for integrating whole branches.
⚠️ Cherry-picking many commits is a sign you might want a merge/rebase instead
⚠️ Conflicts can occur (resolve like a merge); use it deliberately, not as a default
→ Use cherry-pick for SELECTIVE, specific needs — not routine integration.
Zrozumienie git cherry-pick jest wartościowe dla selektywnego stosowania konkretnych zmian, przydatna umiejętność w szczególnych sytuacjach, dlatego warto znać tę praktyczną wiedzę na temat Git.
Zasadnicza umiejętność — stosowanie zmian tylko z konkretnego commita na inną gałąź bez mergowania całej gałęzi — odpowiada rzeczywistym potrzebom, których mergowanie nie potrafi elegancko rozwiązać.
Najczęstszym i najważniejszym zastosowaniem jest backporting: stosowanie konkretnej poprawki błędu z głównej gałęzi do gałęzi wydania lub utrzymania, otrzymując tylko tę poprawkę bez mergowania wszystkich innych (potencjalnie niestabilnych lub niewydanych) zmian z main do gałęzi wydania — częsta potrzeba przy utrzymywaniu wydanego oprogramowania.
Inne zastosowania obejmują stosowanie pojedynczego gotowego commita, gdy reszta jego gałęzi nie jest gotowa, przenoszenie commita stworzonego na złej gałęzi na właściwą, oraz selektywne pobieranie jednej zmiany.
Zrozumienie ostrzeżeń jest ważne dla odpowiedniego stosowania cherry-pick: tworzy duplikaty commitów (te same zmiany z różnymi hashami na każdej gałęzi), co może powodować zamieszanie lub konflikty, jeśli gałęzie zostaną później zmergowane, dlatego powinien być używany celowo do selektywnych potrzeb zamiast jako rutynowa metoda integracji (merge lub rebase są lepsze do integrowania całych gałęzi), a cherry-picking wielu commitów jest znakiem, że prawdopodobnie chcesz zamiast tego mergowania.
Ta ocena — używanie cherry-pick do konkretnych, selektywnych sytuacji (zwłaszcza backporting) podczas gdy preferujesz merge/rebase do rutynowej integracji — odzwierciedla dobre praktyki Git.
Ponieważ selektywne stosowanie konkretnych zmian (zwłaszcza backporting poprawek do gałęzi wydania) jest rzeczywistą, czasami ważną potrzebą, a cherry-pick jest do tego narzędziem (z ostrzeżeniami na temat jego odpowiedniego użycia), zrozumienie git cherry-pick — jak on działa, jego kluczowe przypadki użycia takie jak backporting, i kiedy go używać w stosunku do merge/rebase — jest wartościową, praktycznie istotną wiedzą Git do obsługi scenariuszy selektywnych zmian, które pojawiają się przy utrzymywaniu i zarządzaniu oprogramowaniem na różnych gałęziach.