Git cherry-pick: meerdere commits, branches, conflicten

TL;DR: git cherry-pick <sha> kopieert één commit van elke branch naar je huidige branch — zelfde patch, nieuwe SHA, geen geschiedenis verplaatst. Voor meerdere commits: som SHAs op of gebruik een bereik (git cherry-pick A..B); let op, dat bereik sluit A uit, dus schrijf A^..B om ‘m mee te nemen. Stopt hij op een conflict: los op, git add, dan git cherry-pick --continue. Cherry-picken is voor het verplaatsen van een specifieke fix — wil je alles uit de andere branch, gebruik dan merge of rebase.

Wat doet git cherry-pick eigenlijk?

Cherry-pick neemt een bestaande commit en past zijn diff toe als een nieuwe commit op je huidige branch. De originele commit blijft waar hij is; de kopie krijgt een verse SHA. Git ‘verplaatst’ niets — wie zich later afvraagt waarom de commit nog op de oude branch staat, ziet precies dit.

Dat kopieer-in-plaats-van-verplaats-model bepaalt wanneer cherry-pick het juiste gereedschap is:

• Je nodig één fix uit een feature-branch op main, nu, zonder de rest te mergen.
• Een hotfix die op de verkeerde branch gecommit werd moet op de juiste belanden.
• Een patch moet gereplayd worden op een release-branch die nooit van main merget.

De aanvullende vaardigheid is weten hoe je een commit die fout bleek weer ongedaan maakt — de mechanica daarvan staat in laatste git-commit ongedaan maken: wijzigingen houden.

Hoe cherry-pick ik een commit van een andere branch?

Zoek de SHA, wissel naar de doelbranch, pick:

# 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

Twee handigheden die je wilt kennen:

• git cherry-pick <branch> pakt de tip-commit van die branch — handig, maar makkelijk per ongeluk gedaan met een verouderd beeld van wat ‘de tip’ is.
• Na de pick bevestigt git log -1 --stat wat er landde. Eén seconde lezen, scheelt een revert.

De commits blijven op feature/payment-fix; verwijder die branch wanneer je wilt — de gepickte kopie op main heeft een eigen SHA en hangt niet af van de oude.

Hoe cherry-pick ik meerdere commits?

Drie vormen, in volgorde van hoe vaak je ze nodig hebt:

# 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

Het A..B-tegenover-A^..B-onderscheid is de klassieke verrassing: A..B sluit A uit. Visualiseer je het bereik vanuit git log en pick je oldest..newest, dan sla je stilletjes de oudste commit over. Is ‘de paar oudste, in volgorde’ het doel, schrijf dan oldest^..newest en de off-by-one verdwijnt.

Om meerdere picks samen te vatten in één commit in plaats van drie: stage zonder te committen met -n / --no-commit en commit één keer:

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

Waarom werkt git cherry-pick niet?

Vier echte oorzaken, in volgorde van frequentie:

1. Een conflict stopte de pick. Git past de patch toe, stuit op een regel die op beide branches veranderde en pauzeert halverwege de reeks:

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

--continue is niet optioneel en niet impliciet — tot je het draait, zit je in een gepauzeerde cherry-pick-reeks en blijft git status dat zeggen.

2. De pick is leeg (‘The previous cherry-pick is now empty’). De wijziging bestaat al op deze branch, vaak door een eerdere pick of een ge-squashte merge. Sla over met git cherry-pick --skip, of forceer een lege commit met --allow-empty als je de markering echt nodig hebt.

3. De commit is een merge-commit. Een merge heeft twee ouders, dus ‘pas deze diff toe’ is dubbelzinnig — git weigert liever dan te gokken. Zeg tegen welke ouder je diff’t:

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

4. Verkeerde working tree of detached HEAD. De pick landt waar HEAD ook wijst. git branch --show-current vóór het picken; print hij niets, dan zit je in detached HEAD en wordt de commit wees zodra je wegswitcht.

Cherry-pick vs merge vs rebase: welke, wanneer?

Commando	Wat er op de doelbranch landt	Geschiedenis	Gebruik wanneer
git cherry-pick <sha>	Alleen de genoemde commit(s)	Kopie, nieuwe SHAs	Eén specifieke fix moet nú verplaatsen
git merge <branch>	Alles op de branch	Merge-commit of fast-forward	Je wilt de hele branch, divergentie zichtbaar
git rebase <base>	Alle branch-commits, gereplayd	Lineair, herschreven SHAs	Je wilt de branch als een schone lineaire reeks
git revert <sha>	Inverse van een commit	Voegt een undo-commit toe	Een gelande commit moet op gedeelde geschiedenis ongedaan

De one-liner: cherry-pick verplaatst een selectie; merge en rebase verplaatsen alles. Cherry-pick pakken om met een branch te ‘syncen’ is een teken dat je eigenlijk een merge wilt — en gaat het om de main van je fork versus upstream, dan staat de volledige routine in een fork syncen met upstream, stap voor stap.

Eén gewoonte om over te slaan: dezelfde commit langdurig in meerdere branches cherry-picken. Elke toekomstige fix op de bronbranch vraagt om een nieuwe pick, en uiteindelijk drijven de branches uit elkaar. Backports naar release-branches zijn een normaal patroon; een permanent parallel universum is dat niet.

De cherry-pick-workflow, samengevat

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

Zoeken, wisselen, picken, verifiëren. Het commando heeft een reputatie van gevaarlijkheid die het niet verdient — de diff past, of hij stopt en vertelt je waarom. De enige echt destructieve fout is picken in de verkeerde branch, en git log -1 vóór je pusht maakt die moeilijk te missen.