Cherry-pick — ano ito, mekanismo at paggamit sa Git

Ano ang Cherry-pick?

Cherry-pick — ay isang utos ng Git na kumukopya ng mga pagbabago mula sa isang tinukoy na commit at inilalapat ang mga ito bilang bagong commit sa kasalukuyang branch. Ang pangalan ay nagmula sa metapora na “pumipili ng seresa”: ang developer ay pumipili lamang ng mga commit na kailangan, hindi pinapansin ang iba.

Hindi tulad ng Merge, ang cherry-pick ay hindi gumagawa ng merge commit at hindi nangangailangan ng buong pagsasama ng mga branch. Hindi tulad ng Rebase, ang cherry-pick ay hindi naglilipat ng pagkakasunod-sunod ng mga commit — tanging ang mga tinukoy. Ginagawa nitong perpektong kasangkapan ang cherry-pick para sa tumpak na paglilipat ng mga pag-aayos.

Ayon sa data ng Atlassian, 2025, ang cherry-pick ay ginagamit sa 47% ng mga koponan na nagtatrabaho nang sabay-sabay sa maraming release branch. Ang cherry-pick ay lalong kailangan sa mobile development, kung saang maraming bersyon ng application (LTS releases) ang sinusuportahan nang sabay-sabay at kinakailangan ang paglilipat ng mga pag-aayos sa pagitan nila.

Mekanismo ng paglilipat

Sa pagpapatakbo ng cherry-pick, kinakalkula ng Git ang diff sa pagitan ng tinukoy na commit at ng magulang nito, pagkatapos ay inilalapat ang diff na ito sa kasalukuyang branch. Kung ang mga pagbabago ay nailapat nang walang conflict — ang Git ay lumilikha ng bagong commit na may parehong mensahe ngunit bagong SHA. Kung may conflict — ang cherry-pick ay i-pause para sa manu-manong paglutas.

Paano gumagana ang Cherry-pick

Sintaks ng cherry-pick ay simple: tukuyin ang hash ng commit na nais mong ilipat. Kokopyahin ng Git ang mga pagbabago sa kasalukuyang branch bilang bagong commit. Ang paglilipat ng maraming commit nang sabay-sabay at buong range ay sinusuportahan.

# Paglilipat ng isang commit sa kasalukuyang branch
git cherry-pick a1b2c3d4

# Paglilipat ng maraming commit
git cherry-pick a1b2c3d4 e5f6g7h8

# Paglilipat ng range ng mga commit (mula a1b2 hanggang f9e8, hindi kasama ang a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Pagkatapos isagawa ang cherry-pick, ang kasalukuyang branch ay tumatanggap ng bagong commit na may mga pagbabago mula sa orihinal. Ang mensahe ng commit ay kinokopya bilang default mula sa orihinal, ngunit maaaring baguhin gamit ang flag na -n (huwag gumawa ng commit) o --edit (baguhin ang mensahe).

Halimbawa ng paglilipat ng pag-aayos

Isaalang-alang ang tipikal na scenario: sa develop ay natagpuan at naayos ang isang kritikal na bug na naroroon din sa release branch na release/v2.0. Kailangan lamang ilipat ang pag-aayos na ito, nang hindi isinasama ang buong develop sa release branch.

# Hanapin ang hash ng commit na may pag-aayos sa develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Lumipat sa release branch
git checkout release/v2.0

# Ilapat ang pag-aayos
git cherry-pick a1b2c3d4

# Kung may conflict — lutasin at magpatuloy
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Ang flag na -x ay nagdaragdag sa mensahe ng commit ng isang sanggunian sa orihinal na SHA: “(cherry picked from commit a1b2c3d4)”. Pinapadali nito ang pagsubaybay kung saan inilipat ang commit. Inirerekomenda ang paggamit ng -x sa lahat ng scenario, maliban sa mga pansamantalang draft.

Paggawa sa mga conflict

Sa conflict, ang cherry-pick ay kumikilos tulad ng merge: humihinto ang Git at minamarkahan ang mga file na may conflict. Nilulutas ng developer ang conflict, ginagawa ang git add at pagkatapos ay git cherry-pick --continue. Para kanselahin — git cherry-pick --abort. Ang flag na --strategy ay nagbibigay-daan upang tukuyin ang estratehiya ng pagsasama (halimbawa, recursive na may mga opsyon).

# Paglutas ng conflict sa cherry-pick
# Ipinapakita ng Git ang mga file na may conflict
git status

# Lutasin nang manu-mano, pagkatapos:
git add pinapayagang_file.kt
git cherry-pick --continue

# O kanselahin ang cherry-pick:
git cherry-pick --abort

Kailan gagamitin ang Cherry-pick

Cherry-pick ay optimal sa mga scenario kung saan kinakailangan ang tumpak na paglilipat ng mga pagbabago nang walang pagsasama ng buong branch. Tingnan natin ang limang pangunahing kaso kung saan ang cherry-pick ang nagiging pinakamahusay na pagpipilian.

• Paglilipat ng hotfix — ang pag-aayos ay natagpuan sa develop, ngunit kailangang ilapat sa release branch (release/v2.0). Ang cherry-pick ay naglilipat lamang ng commit ng pag-aayos, hindi ginagalaw ang mga hindi tapos na feature mula sa develop
• Backport sa mga lumang bersyon — ang pag-aayos para sa kasalukuyang bersyon ay kailangang ilipat sa LTS release. Sa halip na isama ang buong kasalukuyang codebase, ang cherry-pick ay pumipili lamang ng mga kinakailangang commit
• Pagkansela ng commit sa ibang branch — kung ang commit ay ginawa sa maling branch, inililipat ito ng cherry-pick sa tamang branch, at ang orihinal na commit ay kinansela
• Paglilipat ng dokumentasyon — ang mga pagbabago sa README o configuration file na dapat nasa lahat ng branch ay maginhawang ilipat sa pamamagitan ng cherry-pick
• Piling paglalapat — mula sa prototype branch ay kailangan lamang kumuha ng isang matagumpay na commit, nang hindi inililipat ang buong prototype sa pangunahing development

Para sa mobile development, ang cherry-pick ay kritikal na mahalaga sa pagsuporta ng maraming bersyon ng application. Halimbawa, kung ang bug ay natagpuan sa bersyon 3.2 na nailabas na sa Google Play, habang ang develop ay naglalaman ng code para sa bersyon 4.0 — pinapayagan ng cherry-pick na ilipat ang pag-aayos sa branch na v3.x nang hindi isinasama ang lahat ng breaking changes. Ito ay lalong mahalaga para sa mga proyekto kung saan dalawa o higit pang pangunahing bersyon na may magkakaibang API at dependencies ay sinusuportahan nang sabay-sabay.

Halimbawa mula sa praktika: sa isang mobile application ay natuklasan ang crash sa pag-authoreyt sa pamamagitan ng Google Sign-In sa Android 12. Ang pag-aayos ay ipinasok sa develop at nakapasa sa review. Ngunit ang kasalukuyang release branch na v2.5 ay nasa beta testing phase na. Ang cherry-pick ng commit ng pag-aayos mula develop papuntang release/v2.5 ay nagpapahintulot na isama ang pag-aayos sa susunod na release, nang hindi inililipat ang iba pang mga pagbabago na hindi pa handa para sa paglabas.

Sa paggamit ng cherry-pick sa mga mobile project, mahalagang isaalang-alang ang mga dependency: kung ang pag-aayos ay nakakaapekto sa mga file na binago sa develop pagkatapos ng punto ng paghihiwalay ng release branch, ang cherry-pick ay maaaring magdala ng hindi kumpletong set ng mga pagbabago. Sa ganitong mga kaso, kailangan suriin kung ang lahat ng kaugnay na pagbabago ay nailipat din, kung hindi ay maaaring hindi mag-compile ang application o gumana nang hindi tama. Palaging suriin ang build pagkatapos ng cherry-pick bago itulak ang mga pagbabago sa shared branch.

Cherry-pick vs Merge vs Rebase

Tatlong pangunahing kasangkapan ng integrasyon ng mga pagbabago sa Git — merge, rebase at cherry-pick — ay lumulutas ng magkakaibang mga gawain. Ang pagpili ay depende sa kung gaano karaming pagbabago ang kailangang ilipat at kung paano dapat ang hitsura ng kasaysayan.

Merge — kapag kailangang pagsamahin ang dalawang branch nang buo at panatilihin ang impormasyon tungkol sa pagsasanga. Rebase — kapag kailangang i-update ang personal na branch sa kasalukuyang estado na may malinis na kasaysayan. Cherry-pick — kapag isa lamang commit o ilang piling commit ang kailangan.

Sa praktika, ang mga kasangkapang ito ay pinagsasama: ang feature ay binuo na may pana-panahong rebase sa develop, pagkatapos ay isinasama sa pamamagitan ng --no-ff merge, at kapag kailangang ilipat ang pag-aayos sa ibang branch, ginagamit ang cherry-pick. Bawat kasangkapan ay lumulutas ng sarili nitong gawain sa kani-kaniyang yugto.

Mga panganib at limitasyon ng Cherry-pick

Cherry-pick — isang kapaki-pakinabang ngunit potensyal na mapanganib na kasangkapan kung mali o sobra ang paggamit. Ang mga pangunahing panganib ay nauugnay sa pagdodoble ng mga commit, pagkawala ng konteksto at mga conflict sa mga susunod na pagsasama.

• Pagdodoble ng mga commit — kung ang parehong commit ay napunta sa branch sa pamamagitan ng merge, ang Git ay lilikha ng pangalawang commit na kapareho sa mga pagbabago. Pumapangit ito ng kasaysayan at nagpapahirap sa git bisect
• Pagkawala ng konteksto — ang cherry-pick ay naglilipat ng diff, ngunit hindi naglilipat ng impormasyon tungkol sa mga magulang na commit at dependencies. Kung inilapat ng cherry-pick ang commit A nang walang commit B na pinagdedependehan ng A, maaaring lumitaw ang mga lohikal na error
• Mga conflict sa merge — pagkatapos ng cherry-pick, sa buong pagsasama ng mga branch, maaaring makita ng Git ang parehong mga pagbabago nang dalawang beses at lumikha ng mga conflict na maiiwasan sa normal na merge
• Kawalan ng ugnayan — kung wala ang flag na -x hindi mauunawaan na ang commit ay inilipat mula sa ibang branch. Sa paghahanap ng pinagmulan ng pagbabago, ang developer ay maaaring gumugol ng mga oras sa pagtukoy ng pinagmulan ng commit

Mga rekomendasyon para mabawasan ang mga panganib: laging gamitin ang flag na -x upang ipahiwatig ang orihinal na SHA, idokumento ang dahilan ng cherry-pick sa mensahe ng commit, at kung maaari ay gamitin ang merge sa halip na cherry-pick kapag pinapayagan ng konteksto. Kung maraming cherry-pick — isaalang-alang ang muling pagbubuo ng mga branch.

Automation ng mga pagsusuri sa Cherry-pick

Mga CI pipeline ay dapat isaalang-alang ang cherry-pick bilang isang hiwalay na scenario. Inirerekomenda na mag-set up ng awtomatikong pagsusuri: sa paggawa ng cherry-pick commit, sinusuri ng CI kung ang mga binagong file ay tumutugma sa inaasahang set at nagpapatakbo ng mga test para sa mga apektadong module. Binabawasan nito ang panganib ng regression sa tumpak na paglilipat ng mga pagbabago sa pagitan ng mga branch.