Cherry-pick: ano ito, paano ginagawa ang cherry-pick at mga utos ng Git

Ano ang cherry-pick sa Git

Cherry-pick — ay ang utos na git cherry-pick na kumukuha ng mga pagbabago mula sa isang umiiral na commit at inilalapat ang mga ito bilang isang bagong commit sa kasalukuyang branch. Ang orihinal na commit ay nananatili sa lugar nito sa sarili nitong branch, habang ang isang kopya ng mga pagbabago ay nilikha sa target na branch. Ang utos ay kapaki-pakinabang kapag kailangan mong maglipat ng isang partikular na pag-aayos nang hindi inililipat ang buong branch.

Sintaksis: git cherry-pick <commit-hash>. Sinusuri ng Git ang pagkakaiba (diff) ng tinukoy na commit sa parent nito at inilalapat ang pagkakaibang ito sa kasalukuyang branch. Kung ang mga pagbabago ay may kinalaman sa maraming file — lahat sila ay inililipat nang magkakasama. Tinatanggap din ng utos ang mga range: git cherry-pick A..B — lahat ng commit mula A hanggang B, hindi kasama ang A.

Pinapalawak ng mga flag ang mga kakayahan: -n (--no-commit) ay naglalapat ng mga pagbabago sa working directory at index nang hindi lumilikha ng commit — kapaki-pakinabang kapag kailangan mong pagsamahin ang mga pagbabago ng maraming commit sa isa. Ang flag na -x ay nagdaragdag ng linya (cherry picked from commit ...) sa mensahe ng commit, na nagpapadali sa pagsubaybay sa pinagmulan ng mga pagbabago sa kasaysayan.

# Cherry-pick ng isang commit sa pamamagitan ng hash
git cherry-pick a1b2c3d

# Cherry-pick ng maramihang commit (sunud-sunod)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick nang walang awtomatikong commit
git cherry-pick -n a1b2c3d

# Flag -x ay nagdaragdag ng sanggunian sa orihinal na commit
git cherry-pick -x a1b2c3d

Kailan ginagamit ang cherry-pick

Pangunahing senaryo — paglipat ng mga pag-aayos sa pagitan ng mga release branch. Isipin: sa develop ay may natagpuang kritikal na bug at naayos ito. Ang release branch na release/v2.1 ay nahiwalay na at ang bug na ito ay naroroon din. Ang merge ng buong develop sa release ay magdadala ng maraming hindi pa handang code, samantalang ang cherry-pick ng isang commit na may fix ay isang ligtas at tumpak na solusyon.

Pangalawang senaryo — pagbabalik ng mga pagbabago (revert) na may kasunod na pagpapanumbalik. Kung ang isang commit ay naibalik sa pamamagitan ng git revert, at pagkatapos ay lumabas na ang pagbabalik ay mali — ang cherry-pick ng naibalik na commit ay nagpapanumbalik ng mga pagbabago. Ito ay mas tama kaysa sa pagbabalik ng revert, dahil hindi ito lumilikha ng paulit-ulit na mga conflict.

Pangatlong senaryo — pagsasama-sama ng mga commit mula sa iba’t ibang feature branch sa isang test branch para sa integration testing. Sa halip na pagsamahin ang ilang hindi tapos na branch (na may hindi kumpletong code), maaari kang pumili lamang ng mga handa nang commit mula sa bawat isa at subukan ang kanilang pagsasama-sama.

• Mga bugfix — paglipat ng pag-aayos mula develop patungo sa release nang walang hindi tapos na code.
• Hotfix — paglalapat ng pag-aayos mula sa hotfix branch sa main at develop nang sabay.
• Pagbabalik ng maling revert — cherry-pick ng naibalik na commit upang maibalik ang mga pagbabago.
• Pagsubok — pagtitipon ng mga piling commit mula sa iba’t ibang branch para sa pagsusuri ng integrasyon.

Cherry-pick vs rebase at merge

Cherry-pick ay naiiba sa rebase at merge dahil ito ay gumagana sa antas ng mga indibidwal na commit, hindi sa buong branch. Kung ang rebase ay naglilipat ng lahat ng commit ng isang branch, at ang merge ay nagsasama ng dalawang branch, ang cherry-pick ay pumipili lamang ng mga kailangan. Ginagawa nitong mas tumpak na kasangkapan, ngunit mas manual din.

Isa pang pagkakaiba — pagmamay-ari. Sa cherry-pick, ang Git ay nagpapanatili ng may-akda (Author) ng orihinal na commit, ngunit ang committer (Committer) ay ang kasalukuyang gumagamit. Sa mensahe ng commit, maaaring masubaybayan ang pinagmulan sa pamamagitan ng -x flag. Sa rebase, ang may-akda at committer ay parehong kasalukuyang gumagamit na may bagong hash.

Pagganap: ang cherry-pick ng isang commit ay mas mabilis kaysa sa merge ng dalawang branch na may maraming commit. Ngunit kung kailangan mong maglipat ng dose-dosenang commit, mas mainam na gumawa ng pansamantalang branch at magsagawa ng rebase — ito ay mas mahusay at hindi nangangailangan ng pagtukoy ng dose-dosenang hash.

Paglipat ng maramihang commit

Maramihang commit ay maaaring ilipat sa isang utos, sa pamamagitan ng paglista ng kanilang mga hash na pinaghihiwalay ng espasyo: git cherry-pick A B C. Inilalapat ng Git ang mga commit nang sunud-sunod sa tinukoy na pagkakasunod-sunod. Kung ang alinman sa mga commit ay nagdudulot ng conflict, ang cherry-pick ay hihinto at ang developer ay dapat magresolba ng conflict, pagkatapos nito ay maaaring magpatuloy sa utos na git cherry-pick --continue.

Range ng commit: git cherry-pick A..B (lahat ng commit pagkatapos ng A hanggang B, hindi kasama ang A) at git cherry-pick A^..B (lahat ng commit mula A kasama hanggang B). Ang mga range ay maginhawa kapag kailangan mong ilipat ang lahat ng commit mula sa isang branch ngunit walang relasyon ng parent — halimbawa, kapag naglilipat ng tapos na feature mula sa lumang branch patungo sa bago.

Ang flag na --strategy ay tumutukoy kung paano ilalapat ng Git ang mga pagbabago. Bilang default, ginagamit ang recursive strategy, ngunit maaari mong tukuyin ang ours o theirs para sa awtomatikong pagpili ng panig ng conflict. Ang flag na --mainline ay ginagamit sa cherry-pick ng merge commit — tinutukoy ang numero ng parent (1 o 2) kung saan kinakalkula ang diff.

# Cherry-pick ng range ng commit
git cherry-pick develop~5..develop~2

# Cherry-pick ng merge commit (tukuyin ang parent)
git cherry-pick -m 1 m9n0o1p

# Gamitin ang theirs strategy
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Magpatuloy pagkatapos ng pagresolba ng conflict
git cherry-pick --continue

Mga conflict sa cherry-pick

Mga conflict sa cherry-pick ay nangyayari kapag ang mga pagbabago ng inililipat na commit ay tumama sa parehong mga linya na binago sa target na branch. Ipinapahinto ng Git ang pagpapatupad, minamarkahan ang mga nagkakasalungatang file, at naghihintay ng resolusyon. Sa status, ang mga naturang file ay ipinapakita bilang both modified.

Mga hakbang sa conflict: buksan ang nagkakasalungatang file, hanapin ang mga marker ng conflict (<<<<<<<, =======, >>>>>>>), i-edit ang nilalaman, alisin ang mga marker, isagawa ang git add para sa mga naresolbang file at patakbuhin ang git cherry-pick --continue. Kung hindi malulutas ang conflict — ang git cherry-pick --abort ay kumakansela sa buong cherry-pick, ibinabalik ang branch sa orihinal na estado.

Madalas na problema: ang commit ay naglalaman na ng mga pagbabagong katumbas ng umiiral na. Sa kasong ito, ang Git ay nag-uulat ng «nothing to commit» o «empty commit» kapag sinusubukan ang cherry-pick. Ang mga flag na --keep-redundant-commits at --empty=keep ay pumipilit sa Git na lumikha ng walang laman na commit upang mapanatili ang pagkakasunod-sunod, habang ang --skip ay nagpapahintulot na laktawan ang naturang commit.

# Conflict sa cherry-pick — huminto
git cherry-pick a1b2c3d
# error: could not apply a1b2c3d... commit message

# Resolbahin ang conflict → idagdag sa index
git add src/conflicted_file.swift
git cherry-pick --continue

# Laktawan ang walang laman na commit (naisagawa na)
git cherry-pick --skip

# Buong pagkansela
git cherry-pick --abort

Pinakamahuhusay na kasanayan sa cherry-pick

Unang panuntunan: palaging suriin kung ang inililipat na commit ay nakatayo nang mag-isa. Kung ang commit A ay nakadepende sa mga pagbabago sa commit B na hindi inililipat, ang cherry-pick ng A ay maaaring makasira sa build. Bago ang cherry-pick, mainam na suriin kung anong mga file ang binago ng commit sa pamamagitan ng git show --stat <hash>.

Ikalawang panuntunan: idokumento ang cherry-pick. Gamitin ang flag na -x upang ang mensahe ng commit ay maglaman ng sanggunian sa orihinal na commit. Makakatulong ito sa susunod na pagsusuri ng kasaysayan upang maunawaan kung saan nagmula ang pagbabago. Kung wala ang -x, ang cherry-pick ay mukhang isang ordinaryong commit, at ang pinagmulan nito ay maaari lamang matukoy sa pamamagitan ng git log --graph.

Ikatlong panuntunan: iwasan ang cherry-pick sa pagitan ng mga branch na masyadong magkalayo. Kung maraming oras na ang lumipas mula nang gawin ang commit at ang codebase ay malaki na ang pagbabago, ang mga conflict ay magiging marami at kumplikado. Sa ganitong mga kaso, mas mainam na gawin muli ang fix sa target na branch — ito ay kukuha ng mas kaunting oras kaysa sa paglutas ng dose-dosenang conflict.

• Cherry-pick lamang ang mga nakatayang mag-isang commit na walang panlabas na dependencies.
• Flag -x ay kinakailangan para sa pagdokumento ng pinagmulan ng commit sa mensahe.
• Iwasan ang cherry-pick ng mga lumang commit na may malaking pagkakaiba sa codebase.
• CI/CD suriin ang build pagkatapos ng cherry-pick: maaaring walang conflict, ngunit ang code ay maaaring hindi mag-compile.
• Komento sa PR kapag lumilikha ng pull request, tukuyin kung aling mga commit ang inilipat sa pamamagitan ng cherry-pick.