Зачерипикнути: шта је то, како се изводи 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 у односу на 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
# грешка: не може да примени a1b2c3d... поруку комита

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

# Прескочи празан комит (већ примењен)
git cherry-pick --skip

# Потпуни прекид (abort)
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-ом.