Cherry-pick — wat is het, mechanisme en toepassing in Git

Wat is Cherry-pick?

Cherry-pick — is een Git-commando dat wijzigingen van een opgegeven commit kopieert en deze toepast als een nieuwe commit in de huidige branch. De naam komt van de metafoor “kersen plukken”: de ontwikkelaar selecteert alleen de commits die hij nodig heeft en negeert de rest.

In tegenstelling tot Merge maakt cherry-pick geen merge-commit aan en vereist het geen volledige samenvoeging van branches. In tegenstelling tot Rebase verplaatst cherry-pick geen reeks commits — alleen de opgegeven. Dit maakt cherry-pick een ideaal hulpmiddel voor gerichte overzetting van fixes.

Volgens gegevens van Atlassian, 2025 wordt cherry-pick gebruikt in 47% van de teams die met meerdere release-branches tegelijk werken. Cherry-pick is vooral gewild in mobiele ontwikkeling, waar meerdere versies van de applicatie (LTS-releases) tegelijk worden ondersteund en fixes tussen hen moeten worden overgezet.

Overzettingsmechanisme

Bij het uitvoeren van cherry-pick berekent Git de diff tussen de opgegeven commit en de parent, en past deze diff vervolgens toe op de huidige branch. Als de wijzigingen zonder conflict worden toegepast — maakt Git een nieuwe commit met hetzelfde bericht maar een nieuwe SHA. Als er een conflict is — wordt cherry-pick gepauzeerd voor handmatige resolutie.

Hoe werkt Cherry-pick

Syntaxis van cherry-pick is eenvoudig: geef de hash op van de commit die je wilt overzetten. Git kopieert de wijzigingen naar de huidige branch als een nieuwe commit. Het overzetten van meerdere commits tegelijk en hele reeksen wordt ondersteund.

# Eén commit overzetten naar de huidige branch
git cherry-pick a1b2c3d4

# Meerdere commits overzetten
git cherry-pick a1b2c3d4 e5f6g7h8

# Reeks commits overzetten (van a1b2 tot f9e8, exclusief a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Na uitvoering van cherry-pick ontvangt de huidige branch een nieuwe commit met wijzigingen uit de originele. Het commit-bericht wordt standaard gekopieerd van de originele, maar kan worden gewijzigd met de vlag -n (geen commit maken) of --edit (bericht bewerken).

Voorbeeld van het overzetten van een fix

Beschouw een typisch scenario: in develop is een kritieke bug gevonden en opgelost die ook aanwezig is in de release-branch release/v2.0. Alleen deze fix moet worden overgezet, zonder de hele develop in de release-branch samen te voegen.

# Vind de hash van de commit met de fix in develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Schakel naar de release-branch
git checkout release/v2.0

# Pas de fix toe
git cherry-pick a1b2c3d4

# Als er een conflict is — los het op en ga verder
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

De vlag -x voegt een verwijzing naar de originele SHA toe aan het commit-bericht: “(cherry picked from commit a1b2c3d4)”. Dit vergemakkelijkt het traceren van waar de commit vandaan is overgezet. Het wordt aanbevolen om -x te gebruiken in alle scenario's, behalve tijdelijke concepten.

Werken met conflicten

Bij conflict gedraagt cherry-pick zich als merge: Git stopt en markeert de conflicterende bestanden. De ontwikkelaar lost het conflict op, voert git add uit en vervolgens git cherry-pick --continue. Voor annulering — git cherry-pick --abort. De vlag --strategy maakt het mogelijk om een samenvoegstrategie op te geven (bijv. recursive met opties).

# Conflict oplossen bij cherry-pick
# Git toont conflicterende bestanden
git status

# Handmatig oplossen, vervolgens:
git add toegestaan_bestand.kt
git cherry-pick --continue

# Of cherry-pick annuleren:
git cherry-pick --abort

Wanneer Cherry-pick toepassen

Cherry-pick is optimaal in scenario's waar gerichte overzetting van wijzigingen nodig is zonder samenvoeging van hele branches. Laten we vijf hoofdgevallen bekijken waarin cherry-pick de beste keuze is.

• Hotfix overzetten — de fix is gevonden in develop, maar moet worden toegepast in de release-branch (release/v2.0). Cherry-pick zet alleen de commit van de fix over, zonder onvoltooide features uit develop aan te raken
• Backport naar oude versies — de fix voor de huidige versie moet worden overgezet naar de LTS-release. In plaats van de hele huidige codebase samen te voegen, selecteert cherry-pick alleen de benodigde commits
• Commit annuleren in een andere branch — als een commit in de verkeerde branch is gemaakt, zet cherry-pick deze over naar de juiste branch en wordt de originele commit geannuleerd
• Documentatie overzetten — wijzigingen in README of configuratiebestanden die in alle branches moeten staan, kunnen gemakkelijk via cherry-pick worden overgezet
• Selectief toepassen — uit de prototype-branch hoeft slechts één succesvolle commit te worden gehaald, zonder het hele prototype naar de hoofdontwikkeling over te zetten

Voor mobiele ontwikkeling is cherry-pick van cruciaal belang bij het ondersteunen van meerdere versies van de applicatie. Bijvoorbeeld, als een bug is gevonden in versie 3.2 die al in Google Play is uitgebracht, terwijl develop code voor versie 4.0 bevat — maakt cherry-pick het mogelijk om de fix naar de v3.x branch over te zetten zonder alle breaking changes samen te voegen. Dit is vooral relevant voor projecten waar twee of meer hoofdversies met verschillende API's en afhankelijkheden tegelijk worden ondersteund.

Voorbeeld uit de praktijk: in een mobiele applicatie is een crash ontdekt bij autorisatie via Google Sign-In op Android 12. De fix is in develop ingevoerd en heeft een review doorstaan. De huidige release-branch v2.5 bevindt zich echter al in de bètatestfase. Cherry-pick van de fix-commit van develop naar release/v2.5 maakt het mogelijk om de fix in de volgende release op te nemen, zonder de overige wijzigingen over te zetten die nog niet klaar zijn voor uitgave.

Bij gebruik van cherry-pick in mobiele projecten is het belangrijk om rekening te houden met afhankelijkheden: als de fix bestanden beïnvloedt die in develop zijn gewijzigd na het splitspunt van de release-branch, kan cherry-pick een onvolledige set wijzigingen opleveren. In dergelijke gevallen moet worden gecontroleerd of alle gerelateerde wijzigingen ook zijn overgezet, anders kan de applicatie niet compileren of incorrect werken. Controleer altijd de build na cherry-pick voordat je wijzigingen naar de gemeenschappelijke branch pusht.

Cherry-pick vs Merge vs Rebase

Drie belangrijkste hulpmiddelen voor het integreren van wijzigingen in Git — merge, rebase en cherry-pick — lossen verschillende taken op. De keuze hangt af van hoeveel wijzigingen moeten worden overgezet en hoe de geschiedenis eruit moet zien.

Merge — wanneer twee branches volledig moeten worden samengevoegd en informatie over vertakking behouden moet blijven. Rebase — wanneer een persoonlijke branch moet worden bijgewerkt naar de huidige staat met een schone geschiedenis. Cherry-pick — wanneer slechts één commit of enkele geselecteerde commits nodig zijn.

In de praktijk worden deze hulpmiddelen gecombineerd: een feature wordt ontwikkeld met periodieke rebase op develop, vervolgens samengevoegd via --no-ff merge, en wanneer een fix naar een andere branch moet worden overgezet, wordt cherry-pick gebruikt. Elk hulpmiddel lost zijn eigen taak in zijn eigen fase op.

Risico's en beperkingen van Cherry-pick

Cherry-pick — een nuttig maar potentieel gevaarlijk hulpmiddel bij onjuist of overmatig gebruik. De belangrijkste risico's houden verband met duplicatie van commits, contextverlies en conflicten bij latere samenvoegingen.

• Duplicatie van commits — als dezelfde commit later via merge in de branch terechtkomt, maakt Git een tweede commit aan die identiek is qua wijzigingen. Dit vervuilt de geschiedenis en bemoeilijkt git bisect
• Contextverlies — cherry-pick zet de diff over, maar niet de informatie over parent-commits en afhankelijkheden. Als cherry-pick commit A heeft toegepast zonder commit B waar A van afhankelijk was, kunnen logische fouten ontstaan
• Conflicten bij merge — na cherry-pick kan Git bij volledige samenvoeging van branches dezelfde wijzigingen twee keer zien en conflicten creëren die bij normale merge vermeden hadden kunnen worden
• Gebrek aan verband — zonder de vlag -x is het onmogelijk te begrijpen dat een commit uit een andere branch is overgezet. Bij het zoeken naar de oorsprong van een wijziging kan de ontwikkelaar uren besteden aan het achterhalen van de herkomst van de commit

Aanbevelingen om risico's te minimaliseren: gebruik altijd de vlag -x om de originele SHA aan te geven, documenteer de reden van cherry-pick in het commit-bericht, en gebruik waar mogelijk merge in plaats van cherry-pick wanneer de context dit toelaat. Als er veel cherry-picks zijn — overweeg herstructurering van branches.

Automatisering van controles bij Cherry-pick

CI-pijplijnen moeten cherry-pick als een apart scenario beschouwen. Het wordt aanbevolen om een geautomatiseerde controle in te stellen: bij het aanmaken van een cherry-pick-commit controleert CI of de gewijzigde bestanden overeenkomen met de verwachte set en voert tests uit voor de getroffen modules. Dit vermindert het risico op regressie bij gerichte overzetting van wijzigingen tussen branches.