Cherry-picken: wat het is, hoe cherry-pick wordt uitgevoerd en Git-commando’s

Wat is cherry-pick in Git

Cherry-pick — is het git cherry-pick commando dat wijzigingen uit een bestaande commit haalt en deze toepast als een nieuwe commit in de huidige branch. De originele commit blijft op zijn plaats in zijn eigen branch, terwijl in de doelbranch een kopie van de wijzigingen wordt gemaakt. Het commando is handig wanneer je een specifieke correctie wilt overzetten zonder de hele branch te verplaatsen.

Syntaxis: git cherry-pick <commit-hash>. Git analyseert het verschil (diff) van de opgegeven commit met zijn parent en past dit verschil toe op de huidige branch. Als de wijzigingen meerdere bestanden betreffen, worden ze allemaal samen overgezet. Het commando accepteert ook bereiken: git cherry-pick A..B — alle commits van A tot B, exclusief A.

Flags breiden de mogelijkheden uit: -n (--no-commit) past wijzigingen toe op de werkdirectory en index zonder een commit te maken — handig wanneer je wijzigingen van meerdere commits in één wilt samenvoegen. De flag -x voegt een regel (cherry picked from commit ...) toe aan het commitbericht, wat het traceren van de oorsprong van wijzigingen in de geschiedenis vereenvoudigt.

# Cherry-pick van een enkele commit via hash
git cherry-pick a1b2c3d

# Cherry-pick van meerdere commits (achtereenvolgens)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick zonder automatische commit
git cherry-pick -n a1b2c3d

# Flag -x voegt verwijzing naar originele commit toe
git cherry-pick -x a1b2c3d

Wanneer gebruik je cherry-pick

Het belangrijkste scenario — het overzetten van correcties tussen release-branches. Stel je voor: in develop is een kritieke bug gevonden en gerepareerd. De release-branch release/v2.1 is al afgesplitst en bevat ook deze bug. Merge van de hele develop naar release brengt veel onvoltooide code over, terwijl cherry-pick van één fix-commit een veilige en precieze oplossing is.

Het tweede scenario — het ongedaan maken van wijzigingen (revert) met later herstel. Als een commit via git revert is teruggedraaid en later blijkt dat de revert onterecht was, herstelt cherry-pick van de teruggedraaide commit de wijzigingen. Dit is correcter dan het terugdraaien van de revert, omdat het geen herhaalde conflicten veroorzaakt.

Het derde scenario — het samenvoegen van commits uit verschillende feature-branches in één testbranch voor integratietesten. In plaats van meerdere onvoltooide branches (met onafgewerkte code) samen te voegen, kun je alleen de voltooide commits uit elke branch selecteren en hun samenwerking testen.

• Bugfixes — correctie overzetten van develop naar release zonder onvoltooide code.
• Hotfix — correctie uit een hotfix-branch tegelijk toepassen op main en develop.
• Ongedaan maken van onterechte revert — cherry-pick van de teruggedraaide commit om wijzigingen te herstellen.
• Testen — verzamelen van geselecteerde commits uit verschillende branches voor integratiecontrole.

Cherry-pick vs rebase en merge

Cherry-pick verschilt van rebase en merge doordat het werkt op het niveau van individuele commits, niet van hele branches. Terwijl rebase alle commits van een branch overzet en merge twee branches samenvoegt, selecteert cherry-pick alleen de gewenste. Dit maakt het een preciezer instrument, maar ook handmatiger.

Nog een verschil — auteurschap. Bij cherry-pick behoudt Git standaard de auteur (Author) van de originele commit, maar de committer (Committer) wordt de huidige gebruiker. In het commitbericht kan de oorsprong worden getraceerd via de -x flag. Bij rebase zijn zowel auteur als committer de huidige gebruiker met een nieuwe hash.

Prestaties: cherry-pick van één commit is sneller dan merge van twee branches met veel commits. Maar als je tientallen commits moet overzetten, kun je beter een tijdelijke branch maken en rebase uitvoeren — dat is efficiënter en vereist niet het opgeven van tientallen hashes.

Meerdere commits overzetten

Meerdere commits kunnen met één commando worden overgezet door hun hashes met spaties te scheiden: git cherry-pick A B C. Git past de commits achtereenvolgens in de opgegeven volgorde toe. Als een van de commits een conflict veroorzaakt, wordt cherry-pick onderbroken en moet de ontwikkelaar het conflict oplossen, waarna hij kan doorgaan met git cherry-pick --continue.

Commitbereik: git cherry-pick A..B (alle commits na A tot B, exclusief A) en git cherry-pick A^..B (alle commits van A inclusief tot B). Bereiken zijn handig wanneer je alle commits uit één branch wilt overzetten zonder de parent-relatie — bijvoorbeeld bij het overzetten van een voltooide feature van een oude naar een nieuwe branch.

De flag --strategy bepaalt hoe Git de wijzigingen toepast. Standaard wordt de recursive-strategie gebruikt, maar je kunt ours of theirs opgeven voor automatische selectie van de conflictzijde. De flag --mainline wordt gebruikt bij cherry-pick van een merge-commit — geeft het parentnummer (1 of 2) aan ten opzichte waarvan de diff wordt berekend.

# Cherry-pick van commitbereik
git cherry-pick develop~5..develop~2

# Cherry-pick van merge-commit (parent specificeren)
git cherry-pick -m 1 m9n0o1p

# Theirs-strategie gebruiken
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Doorgaan na conflictoplossing
git cherry-pick --continue

Conflicten bij cherry-pick

Conflicten bij cherry-pick ontstaan wanneer de wijzigingen van de over te zetten commit dezelfde regels betreffen die in de doelbranch zijn gewijzigd. Git onderbreekt de uitvoering, markeert de conflicterende bestanden en wacht op oplossing. In de status worden dergelijke bestanden weergegeven als both modified.

Procedure bij een conflict: open het conflicterende bestand, zoek de conflictmarkeringen (<<<<<<<, =======, >>>>>>>), bewerk de inhoud, verwijder de markeringen, voer git add uit voor de opgeloste bestanden en start git cherry-pick --continue. Als het conflict onoplosbaar is, annuleert git cherry-pick --abort de hele cherry-pick en keert de branch terug naar de oorspronkelijke staat.

Een veelvoorkomend probleem: de commit bevat al wijzigingen die gelijkwaardig zijn aan bestaande. In dit geval meldt Git «nothing to commit» of «empty commit» bij een cherry-pick-poging. De flags --keep-redundant-commits en --empty=keep dwingen Git om een lege commit te maken om de volgorde te behouden, terwijl --skip zo’n commit overslaat.

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

# Conflict oplossen → toevoegen aan index
git add src/conflicted_file.swift
git cherry-pick --continue

# Lege commit overslaan (al toegepast)
git cherry-pick --skip

# Volledig annuleren
git cherry-pick --abort

Beste praktijken voor cherry-pick

Eerste regel: controleer altijd of de over te zetten commit zelfstandig is. Als commit A afhankelijk is van wijzigingen in commit B die niet wordt overgezet, kan cherry-pick van A de build breken. Voor cherry-pick is het nuttig om te controleren welke bestanden de commit heeft gewijzigd via git show --stat <hash>.

Tweede regel: documenteer cherry-pick. Gebruik de flag -x zodat het commitbericht een verwijzing naar de originele commit bevat. Dit helpt bij latere analyse van de geschiedenis om te begrijpen waar de wijziging vandaan komt. Zonder -x ziet cherry-pick eruit als een gewone commit en kan de oorsprong alleen worden achterhaald via git log --graph.

Derde regel: vermijd cherry-pick tussen branches die te ver uit elkaar lopen. Als er veel tijd is verstreken sinds het maken van de commit en de codebasis aanzienlijk is veranderd, zullen de conflicten talrijk en complex zijn. In dergelijke gevallen is het beter om de fix opnieuw in de doelbranch te maken — dat kost minder tijd dan het oplossen van tientallen conflicten.

• Cherry-pick alleen zelfstandige commits zonder externe afhankelijkheden.
• Flag -x is verplicht voor het documenteren van de oorsprong van de commit.
• Vermijd cherry-pick van oude commits met een grote afwijking in de codebasis.
• CI/CD controleer de build na cherry-pick: er hoeft geen conflict te zijn, maar de code kan nog steeds niet compileren.
• Opmerking in PR vermeld bij het aanmaken van een pull request welke commits via cherry-pick zijn overgezet.