Cherry-pick — що це таке, механізм та застосування в Git

Що таке Cherry-pick?

Cherry-pick — це команда Git, яка копіює зміни з вказаного коміту та застосовує їх як новий коміт у поточній гілці. Назва походить від метафори «вибирати вишеньки»: розробник вибирає тільки ті коміти, які потрібні, ігноруючи решту.

На відміну від Merge, cherry-pick не створює merge-коміт і не вимагає повного злиття гілок. На відміну від Rebase, cherry-pick не переносить послідовність комітів — тільки вказані. Це робить cherry-pick ідеальним інструментом для точкового перенесення виправлень.

За даними Atlassian, 2025, cherry-pick використовується в 47% команд, які працюють з кількома релізними гілками одночасно. Особливо затребуваний cherry-pick у мобільній розробці, де одночасно підтримуються кілька версій застосунку (LTS-релізи) і потрібно переносити виправлення між ними.

Механізм перенесення

При виконанні cherry-pick Git обчислює diff між вказаним комітом та його батьком, потім застосовує цей diff до поточної гілки. Якщо зміни застосувалися без конфлікту — Git створює новий коміт із тим самим повідомленням, але новим SHA. Якщо є конфлікт — cherry-pick призупиняється для ручного вирішення.

Як працює Cherry-pick

Синтаксис cherry-pick простий: вкажіть хеш коміту, який потрібно перенести. Git скопіює зміни в поточну гілку як новий коміт. Підтримується перенесення кількох комітів за раз і цілих діапазонів.

# Перенесення одного коміту в поточну гілку
git cherry-pick a1b2c3d4

# Перенесення кількох комітів
git cherry-pick a1b2c3d4 e5f6g7h8

# Перенесення діапазону комітів (від a1b2 до f9e8, не включаючи a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Після виконання cherry-pick поточна гілка отримує новий коміт із змінами з вихідного. Повідомлення коміту за замовчуванням копіюється з вихідного, але може бути змінене прапорцем -n (не створювати коміт) або --edit (редагувати повідомлення).

Приклад перенесення виправлення

Розглянемо типовий сценарій: у develop знайдено та виправлено критичний баг, який також присутній у релізній гілці release/v2.0. Потрібно перенести тільки цей фікс, не зливаючи весь develop у релізну гілку.

# Знайти хеш коміту з виправленням у develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Переключитися на релізну гілку
git checkout release/v2.0

# Застосувати виправлення
git cherry-pick a1b2c3d4

# Якщо конфлікт — вирішити та продовжити
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Прапорець -x додає в повідомлення коміту посилання на вихідний SHA: «(cherry picked from commit a1b2c3d4)». Це спрощує відстеження, звідки було перенесено коміт. Рекомендується використовувати -x у всіх сценаріях, крім тимчасових чернеток.

Робота з конфліктами

При конфлікті cherry-pick поводиться як merge: Git зупиняється та позначає конфліктні файли. Розробник вирішує конфлікт, робить git add та виконує git cherry-pick --continue. Для скасування — git cherry-pick --abort. Прапорець --strategy дозволяє вказати стратегію злиття (наприклад, recursive з опціями).

# Вирішення конфлікту при cherry-pick
# Git показує конфліктні файли
git status

# Вирішити вручну, потім:
git add разрешённый_файл.kt
git cherry-pick --continue

# Або скасувати cherry-pick:
git cherry-pick --abort

Коли застосовувати Cherry-pick

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

• Перенесення hotfix — виправлення знайдено в develop, але потрібно застосувати його в релізній гілці (release/v2.0). Cherry-pick переносить тільки коміт фіксу, не зачіпаючи незавершені фічі з develop
• Backport у старі версії — виправлення для поточної версії потрібно перенести в LTS-реліз. Замість злиття всієї поточної кодової бази cherry-pick вибирає тільки потрібні коміти
• Скасування коміту в іншій гілці — якщо коміт було зроблено не в ту гілку, cherry-pick переносить його в правильну, а вихідний коміт скасовується
• Перенесення документації — зміни в README або конфігураційних файлах, які повинні бути у всіх гілках, зручно переносити через cherry-pick
• Вибіркове застосування — з гілки-прототипу потрібно взяти лише один вдалий коміт, не переносячи весь прототип в основну розробку

Для мобільної розробки cherry-pick критично важливий при підтримці кількох версій застосунку. Наприклад, якщо баг знайдено у версії 3.2, вже випущеній у Google Play, а develop містить код для версії 4.0 — cherry-pick дозволяє перенести виправлення в гілку v3.x без злиття всіх breaking changes. Це особливо актуально для проєктів, де одночасно підтримуються дві і більше мажорні версії з різними API та залежностями.

Приклад із практики: у мобільному застосунку виявлено crash при авторизації через Google Sign-In на Android 12. Виправлення внесено в develop і пройшло рев’ю. Однак поточна релізна гілка v2.5 вже на етапі beta-тестування. Cherry-pick коміту фіксу з develop у release/v2.5 дозволяє включити виправлення в найближчий реліз, не переносячи інші зміни, які ще не готові до випуску.

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

Cherry-pick vs Merge vs Rebase

Три основні інструменти інтеграції змін у Git — merge, rebase та cherry-pick — вирішують різні завдання. Вибір залежить від того, який обсяг змін потрібно перенести і як має виглядати історія.

Merge — коли потрібно об’єднати дві гілки цілком і зберегти інформацію про розгалуження. Rebase — коли потрібно оновити особисту гілку до актуального стану з чистою історією. Cherry-pick — коли потрібен лише один коміт або кілька вибраних комітів.

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

Ризики та обмеження Cherry-pick

Cherry-pick — корисний, але потенційно небезпечний інструмент при неправильному або надмірному використанні. Основні ризики пов’язані з дублюванням комітів, втратою контексту та конфліктами при подальших злиттях.

• Дублювання комітів — якщо той самий коміт пізніше потрапить у гілку через merge, Git створить другий, ідентичний за змінами коміт. Це забруднює історію та ускладнює git bisect
• Втрата контексту — cherry-pick переносить diff, але не переносить інформацію про батьківські коміти та залежності. Якщо cherry-pick застосував коміт A без коміту B, від якого A залежав, можуть виникнути логічні помилки
• Конфлікти при merge — після cherry-pick при повному злитті гілок Git може побачити ті ж зміни двічі та створити конфлікти, яких можна було уникнути при звичайному merge
• Відсутність зв’язку — без прапорця -x неможливо зрозуміти, що коміт був перенесений з іншої гілки. При пошуку origin зміни розробник може витратити години на з’ясування походження коміту

Рекомендації щодо мінімізації ризиків: завжди використовуйте прапорець -x для вказівки вихідного SHA, документуйте причину cherry-pick у повідомленні коміту, і по можливості використовуйте merge замість cherry-pick, коли це дозволяє контекст. Якщо cherry-pick-ів стає багато — розгляньте реструктуризацію гілок.

Автоматизація перевірок при Cherry-pick

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