Git Cherry Pick: Maramihang Commits, Branches, Conflicts

TL;DR: kinokopya ng git cherry-pick <sha> ang isang commit mula sa kahit anong branch papunta sa current branch mo — parehong patch, bagong SHA, walang inilipat na history. Para sa ilang commits, maglista ng SHAs o gumamit ng range (git cherry-pick A..B); tandaang hindi kasama ang A sa range, kaya isulat ang A^..B para maisama ito. Kapag huminto ito sa conflict, i-resolve, git add, tapos git cherry-pick --continue. Ang cherry-pick ay para sa paglipat ng tukoy na fix — kapag gusto mo ang lahat mula sa ibang branch, mag-merge o mag-rebase ka na lang.

Ano talaga ang ginagawa ng git cherry-pick?

Kumukuha ang cherry-pick ng isang existing commit at inilalapat ang diff nito bilang bagong commit sa current branch mo. Nananatili sa lugar nito ang orihinal na commit; ang kopya ay nakakakuha ng bagong SHA. Hindi “ginagalaw” ng Git ang kahit ano — ang mga taong magtataka kung bakit lumalabas pa rin ang commit sa lumang branch ay eksakto itong nakikita.

Ang copy-not-move na modelong iyan ang nagpapasya kung kailan tamang tool ang cherry-pick:

• Kailangan mo ng isang fix mula sa feature branch papunta sa main ngayon, nang hindi mina-merge ang iba.
• Isang hotfix na nai-commit sa maling branch ang kailangang lumapag sa tamang isa.
• Kailangang i-replay ang isang patch sa release branch na hindi kailanman nagma-merge mula sa main.

Ang katambal na skill ay ang pag-alam kung paano bawiin ang isang commit na pala ay mali — sakop ng git undo last commit: keep the changes ang mekaniks nito.

Paano ko i-cherry-pick ang commit mula sa ibang branch?

Hanapin ang SHA, lumipat sa target branch, pumili:

# 1. Locate the commit on the source branch
git log feature/payment-fix --oneline -5

# 2. Switch to the branch that should receive it
git switch main

# 3. Copy it over
git cherry-pick 1a2b3c4

Dalawang benepisyo na worth malaman:

• Pinipili ng git cherry-pick <branch> ang tip commit ng branch na iyon — madaling gamitin, pero madali ring maisangkapan kapag luma na ang mental model mo kung ano ang “tip”.
• Pagkatapos ng pick, kinukumpirma ng git log -1 --stat kung ano ang lumapag. Isang segundo ng pagbasa, nakakatipid ng isang revert.

Mananatili ang mga commit sa feature/payment-fix; burahin mo ang branch na iyon kahit kailan mo gusto — ang pinicking kopya sa main ay may sariling SHA at walang dependency sa luma.

Paano ko i-cherry-pick ang maraming commits?

Tatlong hugis, ayon sa dalas na gusto mo sila:

# 1. Explicit list — picked in the order you list them
git cherry-pick 1a2b3c4 5d6e7f8

# 2. Range — everything after A up to and including B
git cherry-pick A..B

# 3. Range including A
git cherry-pick A^..B

Ang pagkakaiba ng A..B at A^..B ang klasikong sorpresa: hindi kasama ng A..B ang A. Kapag i-vivisualize mo ang range mula sa git log at pinili ang oldest..newest, tahimik mong nalaktawan ang pinakalumang commit. Kapag “ang pinakalumang ilang commits, sa ayos” ang goal, isulat ang oldest^..newest at mawawala ang off-by-one.

Para isama ang ilang picks sa iisang commit sa halip na tatlo, mag-stage nang walang commit gamit ang -n / --no-commit, tapos mag-commit nang isang beses:

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

Bakit hindi gumagana ang git cherry-pick?

Apat na totoong sanhi, ayon sa dalas:

1. Huminto ang pick dahil sa conflict. Inilalapat ng Git ang patch, nakatagpo ng linyang nagbago sa parehong branches, at humihinto sa gitna ng sequence:

# resolve the files, then:
git add <resolved-files>
git cherry-pick --continue   # or --abort to return to the pre-pick state

Hindi optional at hindi implied ang --continue — hangga’t hindi mo ito niru-run, nasa naka-pause na cherry-pick sequence ka at paulit-ulit itong sasabihin ng git status.

2. Walang laman ang pick (“The previous cherry-pick is now empty”). Umiiral na ang change sa branch na ito — madalas galing sa naunang pick o sa naka-squash na merge. Laktawan ito gamit ang git cherry-pick --skip, o pwersahin ang empty commit gamit ang --allow-empty kung talagang kailangan mo ang marker.

3. Merge commit ang commit. May dalawang parents ang merge, kaya hindi malinaw ang “i-apply ang diff na ito” — tumatanggi ang git sa halip na manghula. Sabihin kung alin ang parent na pinagbabatayan ng diff:

git cherry-pick -m 1 <merge-sha>   # parent 1 = the branch you merged *into*

4. Maling working tree o detached HEAD. Lalapag ang pick kahit saan tumuturo ang HEAD. git branch --show-current bago mag-pick; kapag walang inilabas, nasa detached HEAD ka at ma-o-orphan ang commit kapag lumipat ka.

Cherry-pick vs merge vs rebase: alin kailan?

Command	Ang lumalapag sa target	History	Gamitin kailan
git cherry-pick <sha>	mga pinangalanang commit lang	kopya, bagong mga SHA	isang tukoy na fix ang kailangang ilipat ngayon
git merge <branch>	lahat ng nasa branch	merge commit o fast-forward	gusto mo ang buong branch, nakikita ang divergence
git rebase <base>	lahat ng commit ng branch, naka-replay	linear, binagong mga SHA	gusto mo ang branch bilang malinis na linear na run
git revert <sha>	kabaligtaran ng isang commit	nagdaragdag ng undo commit	kailangang bawiin ang lumapag na commit sa shared history

Ang one-line na tuntunin: pinipili ng cherry-pick ang isang selection; inililipat ng merge at rebase ang lahat. Ang pag-abot sa cherry-pick para “mag-sync” sa isang branch ay senyales na gusto mo talaga ang merge — at kung ang branch ay main ng fork mo laban sa upstream, ang buong routine ay nasa sync a fork with upstream, step by step.

Isang habit na laktawan: paulit-ulit na cherry-pick ng parehong commit sa ilang branches sa mahabang panahon. Ang bawat susunod na fix sa source branch ay mangangailangan ng isa pang pick, at sa kalaunan magkakalayo ang mga branches. Normal na pattern ang mga backport sa mga release branch; ang permanente ng parallel universe, hindi.

Ang cherry-pick workflow, pinaikli

git log <source-branch> --oneline -5   # find the SHA(s)
git switch <target-branch>             # land in the right place
git cherry-pick A^..B                  # range, list, or single SHA
# on conflict: resolve → git add → git cherry-pick --continue
git log -1 --stat                      # confirm what landed

Hanapin, lumipat, pumili, i-verify. May reputasyon ang command sa panganib na hindi nito nararapat — ang diff ay either inilalapat o humihinto at sinasabi sa iyo kung bakit. Ang tanging totoong nakakasirang pagkakamali ay ang pag-pick sa maling branch, at hinahadlangan ng git log -1 bago ka mag-push na mapalampas mo iyon.