Cherry-pick: що це, як виконується та Git-команди

Що таке cherry-pick у Git

Cherry-pick — це команда git cherry-pick, яка бере зміни з існуючого коміту та застосовує їх як новий коміт у поточній гілці. Вихідний коміт залишається на місці у своїй гілці, а в цільовій гілці створюється копія змін. Команда корисна, коли потрібно перенести конкретне виправлення, не переміщуючи всю гілку цілком.

Синтаксис: git cherry-pick <commit-hash>. Git аналізує різницю (diff) указаного коміту з його батьком і застосовує цю різницю до поточної гілки. Якщо змінено кілька файлів — усі вони переносяться разом. Команда приймає також діапазони: git cherry-pick A..B — усі коміти від A до B, не включаючи A.

Флаги розширюють можливості: -n (--no-commit) застосовує зміни до робочої директорії та індексу без створення коміту — корисно, коли потрібно об’єднати зміни кількох комітів в один. Флаг -x додає в повідомлення коміту рядок (cherry picked from commit ...), що спрощує відстеження походження змін в історії.

# Cherry-pick одного коміту за хешем
git cherry-pick a1b2c3d

# Cherry-pick кількох комітів (послідовно)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick без авто-коміту
git cherry-pick -n a1b2c3d

# Флаг -x додає посилання на оригінальний коміт
git cherry-pick -x a1b2c3d

Коли застосовують cherry-pick

Основний сценарій — перенесення виправлень між релізними гілками. Уявіть: у develop знайшли та виправили критичний баг. Релізна гілка release/v2.1 уже відділена, і в ній цей баг також присутній. Merge всього develop у release перенесе багато неготового коду, а cherry-pick одного коміту з фіксом — безпечне та точне рішення.

Другий сценарій — скасування змін (revert) з подальшим відновленням. Якщо коміт було скасовано через git revert, а потім з’ясувалося, що скасування було помилковим — cherry-pick скасованого коміту відновлює зміни. Це коректніше, ніж скасування revert, оскільки не створює повторних конфліктів.

Третій сценарій — об’єднання комітів з різних feature-гілок в одну тестову гілку для інтеграційного тестування. Замість того щоб зливати кілька незавершених гілок (з недоробленим кодом), можна вибрати лише готові коміти з кожної та протестувати їхню спільну роботу.

• Багфікси — перенесення виправлення з develop у release без недоробленого коду.
• Hotfix — застосування виправлення з hotfix-гілки в main та develop одночасно.
• Відкат помилкового revert — cherry-pick скасованого коміту для відновлення змін.
• Тестування — збір вибіркових комітів з різних гілок для інтеграційної перевірки.

Cherry-pick vs rebase та merge

Cherry-pick відрізняється від rebase та merge тим, що працює на рівні окремих комітів, а не гілок цілком. Якщо rebase переносить усі коміти гілки, а merge об’єднує дві гілки, то cherry-pick вибирає лише потрібні. Це робить його більш точним інструментом, але й більш ручним.

Ще одна відмінність — авторство. При cherry-pick Git за замовчуванням зберігає автора оригінального коміту (Author), але комітером (Committer) стає поточний користувач. У повідомленні коміту можна відстежити походження через флаг -x. При rebase автор і комітер — обоє поточний користувач з новим хешем.

Продуктивність: cherry-pick одного коміту виконується швидше, ніж merge двох гілок з великою кількістю комітів. Але якщо потрібно перенести десятки комітів, краще створити тимчасову гілку та виконати rebase — це буде більш ефективно та не потребуватиме вказівки десятків хешів.

Перенесення кількох комітів

Кілька комітів можна перенести однією командою, перерахувавши їхні хеші через пробіл: git cherry-pick A B C. Git застосовує коміти послідовно в указаному порядку. Якщо якийсь із комітів викликає конфлікт, cherry-pick призупиняється, і розробник повинен вирішити конфлікт, після чого продовжити командою git cherry-pick --continue.

Діапазон комітів: git cherry-pick A..B (усі коміти після A до B, не включаючи A) та git cherry-pick A^..B (усі коміти від A включно до B). Діапазони зручні, коли потрібно перенести всі коміти з однієї гілки, але без батьківського зв’язку — наприклад, при перенесенні готової фічі зі старої гілки в нову.

Флаг --strategy визначає, як Git буде застосовувати зміни. За замовчуванням використовується recursive-стратегія, але можна вказати ours або theirs для автоматичного вибору сторони конфлікту. Флаг --mainline використовується при cherry-pick merge-коміту — вказує номер батька (1 або 2), відносно якого обчислюється diff.

# Cherry-pick діапазону комітів
git cherry-pick develop~5..develop~2

# Cherry-pick merge-коміту (вказати батька)
git cherry-pick -m 1 m9n0o1p

# Використати стратегію theirs
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Продовжити після вирішення конфлікту
git cherry-pick --continue

Конфлікти при cherry-pick

Конфлікти при cherry-pick виникають, коли зміни переносного коміту зачіпають ті самі рядки, які були змінені в цільовій гілці. Git призупиняє виконання, позначає конфліктуючі файли та очікує вирішення. У статусі такі файли відображаються як both modified.

Порядок дій при конфлікті: відкрити конфліктуючий файл, знайти маркери конфлікту (<<<<<<<, =======, >>>>>>>), відредагувати вміст, прибрати маркери, виконати git add для вирішених файлів і запустити git cherry-pick --continue. Якщо конфлікт невирішуваний — git cherry-pick --abort скасовує весь cherry-pick, повертаючи гілку у вихідний стан.

Часта проблема: коміт уже містить зміни, еквівалентні існуючим. У цьому випадку Git повідомляє «nothing to commit» або «empty commit» при спробі cherry-pick. Флаги --keep-redundant-commits та --empty=keep змушують Git створювати порожній коміт для збереження послідовності, а --skip дозволяє пропустити такий коміт.

# Конфлікт під час cherry-pick — зупинитись
git cherry-pick a1b2c3d
# error: не вдалося застосувати a1b2c3d... повідомлення коміту

# Вирішити конфлікт → додати до індексу
git add src/conflicted_file.swift
git cherry-pick --continue

# Пропустити порожній коміт (вже застосовано)
git cherry-pick --skip

# Повне скасування
git cherry-pick --abort

Кращі практики cherry-pick

Перше правило: завжди перевіряйте, що переносний коміт самодостатній. Якщо коміт A залежить від змін у коміті B, який не переноситься, cherry-pick A може зламати збірку. Перед cherry-pick корисно перевірити, які файли змінив коміт, через git show --stat <hash>.

Друге правило: документуйте cherry-pick. Використовуйте флаг -x, щоб у повідомленні коміту збереглася посилання на вихідний коміт. Це допоможе при подальшому аналізі історії зрозуміти, звідки взялася зміна. Без -x cherry-pick виглядає як звичайний коміт, і його походження можна встановити лише через git log --graph.

Третє правило: уникайте cherry-pick між гілками, які розходяться занадто сильно. Якщо від моменту створення коміту минуло багато часу та кодова база суттєво змінилася, конфлікти будуть численними та складними. У таких випадках краще зробити фікс заново в цільовій гілці — це займе менше часу, ніж вирішення десятків конфліктів.

• Cherry-pick лише самодостатні коміти без зовнішніх залежностей.
• Флаг -x обов’язковий для документування походження коміту в повідомленні.
• Уникайте cherry-pick старих комітів із великим розходженням кодової бази.
• CI/CD перевіряйте збірку після cherry-pick: конфлікт міг не виникнути, але код може не компілюватися.
• Коментар у PR при створенні pull request вказуйте, які коміти були перенесені cherry-pick.