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 је већ у фази бета тестирања. 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 немогуће је разумети да је комит пренет из друге гране. При тражењу порекла измене, програмер може потрошити сате на утврђивање порекла комита

Препоруке за минимизацију ризика: увек користите заставицу -x за навођење оригиналног SHA, документујте разлог cherry-pick-а у поруци комита, и када је могуће користите merge уместо cherry-pick-а када контекст дозвољава. Ако cherry-pick-ова има много — размотрите реструктурирање грана.

Аутоматизација провера при Cherry-pick-у

CI пајплајнови треба да узму у обзир cherry-pick као посебан сценарио. Препоручује се подешавање аутоматске провере: при стварању cherry-pick комита CI проверава да ли измењене датотеке одговарају очекиваном скупу и покреће тестове за погођене модуле. Ово смањује ризик од регресије при прецизном преносу измена између грана.