Cherry-pick — vad det är, mekanism och tillämpning i Git

Vad är Cherry-pick?

Cherry-pick — är ett Git-kommando som kopierar ändringar från en angiven commit och tillämpar dem som en ny commit i den aktuella grenen. Namnet kommer från metaforen ”plocka körsbär”: utvecklaren väljer endast de commits som behövs och ignorerar resten.

Till skillnad från Merge skapar cherry-pick ingen merge-commit och kräver ingen fullständig sammanslagning av grenar. Till skillnad från Rebase överför cherry-pick ingen sekvens av commits — endast de angivna. Detta gör cherry-pick till ett idealiskt verktyg för punktöverföring av korrigeringar.

Enligt uppgifter från Atlassian, 2025 används cherry-pick i 47% av teamen som arbetar med flera release-grenar samtidigt. Cherry-pick är särskilt efterfrågat inom mobilutveckling, där flera versioner av applikationen (LTS-releaser) stöds samtidigt och korrigeringar behöver överföras mellan dem.

Överföringsmekanism

Vid körning av cherry-pick beräknar Git diff mellan den angivna commiten och dess förälder, och tillämpar sedan denna diff på den aktuella grenen. Om ändringarna tillämpades utan konflikt — skapar Git en ny commit med samma meddelande men nytt SHA. Om det finns en konflikt — pausas cherry-pick för manuell lösning.

Hur Cherry-pick fungerar

Syntax för cherry-pick är enkel: ange hashen för den commit du vill överföra. Git kopierar ändringarna till den aktuella grenen som en ny commit. Överföring av flera commits samtidigt och hela intervall stöds.

# Överföring av en commit till aktuell gren
git cherry-pick a1b2c3d4

# Överföring av flera commits
git cherry-pick a1b2c3d4 e5f6g7h8

# Överföring av commit-intervall (från a1b2 till f9e8, exklusive a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Efter körning av cherry-pick får den aktuella grenen en ny commit med ändringar från originalet. Commit-meddelandet kopieras som standard från originalet, men kan ändras med flaggan -n (skapa inte commit) eller --edit (redigera meddelande).

Exempel på överföring av korrigering

Betrakta ett typiskt scenario: i develop hittades och åtgärdades ett kritiskt fel som även finns i release-grenen release/v2.0. Endast denna korrigering behöver överföras, utan att hela develop slås samman med release-grenen.

# Hitta hashen för commiten med korrigeringen i develop
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Växla till release-grenen
git checkout release/v2.0

# Tillämpa korrigeringen
git cherry-pick a1b2c3d4

# Om det finns en konflikt — lös den och fortsätt
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Flaggan -x lägger till en referens till det ursprungliga SHA i commit-meddelandet: ”(cherry picked from commit a1b2c3d4)”. Detta underlättar spårning av var commiten överfördes ifrån. Det rekommenderas att använda -x i alla scenarier utom tillfälliga utkast.

Arbeta med konflikter

Vid konflikt beter sig cherry-pick som merge: Git stannar och markerar konfliktfiler. Utvecklaren löser konflikten, utför git add och därefter git cherry-pick --continue. För avbrytning — git cherry-pick --abort. Flaggan --strategy gör det möjligt att ange sammanslagningsstrategi (t.ex. recursive med alternativ).

# Lösning av konflikt vid cherry-pick
# Git visar konfliktfiler
git status

# Lös manuellt, därefter:
git add tillåten_fil.kt
git cherry-pick --continue

# Eller avbryt cherry-pick:
git cherry-pick --abort

När ska Cherry-pick tillämpas

Cherry-pick är optimalt i scenarier där punktöverföring av ändringar krävs utan sammanslagning av hela grenar. Låt oss titta på fem huvudfall där cherry-pick blir det bästa valet.

• Överföring av hotfix — korrigeringen hittades i develop men måste tillämpas i release-grenen (release/v2.0). Cherry-pick överför endast korrigeringscommit utan att påverka ofärdiga funktioner från develop
• Backport till gamla versioner — korrigeringen för den aktuella versionen måste överföras till LTS-releasen. Istället för att slå samman hela den aktuella kodbasen väljer cherry-pick endast de nödvändiga commitsen
• Avbrytning av commit i annan gren — om en commit gjordes i fel gren överför cherry-pick den till rätt gren och den ursprungliga commiten avbryts
• Överföring av dokumentation — ändringar i README eller konfigurationsfiler som ska finnas i alla grenar kan enkelt överföras via cherry-pick
• Selektiv tillämpning — från prototypgrenen behöver endast en framgångsrik commit hämtas, utan att hela prototypen överförs till huvudutvecklingen

För mobilutveckling är cherry-pick kritiskt viktigt vid stöd för flera versioner av applikationen. Till exempel, om ett fel hittas i version 3.2 som redan släppts i Google Play, medan develop innehåller kod för version 4.0 — gör cherry-pick det möjligt att överföra korrigeringen till grenen v3.x utan att slå samman alla breaking changes. Detta är särskilt relevant för projekt där två eller fler huvudversioner med olika API:er och beroenden stöds samtidigt.

Exempel från praktiken: i en mobilapplikation upptäcktes en krasch vid autentisering via Google Sign-In på Android 12. Korrigeringen fördes in i develop och godkändes vid granskning. Den aktuella release-grenen v2.5 är dock redan i betatestningsfasen. Cherry-pick av korrigeringscommit från develop till release/v2.5 gör det möjligt att inkludera korrigeringen i nästa release utan att överföra övriga ändringar som ännu inte är redo för lansering.

Vid användning av cherry-pick i mobilprojekt är det viktigt att ta hänsyn till beroenden: om korrigeringen påverkar filer som ändrats i develop efter förgreningspunkten för release-grenen, kan cherry-pick medföra en ofullständig uppsättning ändringar. I sådana fall måste man kontrollera att alla relaterade ändringar också har överförts, annars kan applikationen inte kompileras eller fungera korrekt. Kontrollera alltid bygget efter cherry-pick innan du pushar ändringar till den gemensamma grenen.

Cherry-pick vs Merge vs Rebase

Tre huvudverktyg för integrering av ändringar i Git — merge, rebase och cherry-pick — löser olika uppgifter. Valet beror på hur många ändringar som behöver överföras och hur historiken ska se ut.

Merge — när två grenar behöver slås samman fullständigt och information om förgrening bevaras. Rebase — när en personlig gren behöver uppdateras till aktuellt tillstånd med ren historik. Cherry-pick — när endast en commit eller några få valda commits behövs.

I praktiken kombineras dessa verktyg: funktionen utvecklas med periodisk rebase på develop, slås sedan samman via --no-ff merge, och när en korrigering behöver överföras till en annan gren används cherry-pick. Varje verktyg löser sin uppgift i sitt skede.

Risker och begränsningar med Cherry-pick

Cherry-pick — ett användbart men potentiellt farligt verktyg vid felaktig eller överdriven användning. De främsta riskerna är relaterade till duplicering av commits, förlust av sammanhang och konflikter vid efterföljande sammanslagningar.

• Duplicering av commits — om samma commit senare kommer in i grenen via merge skapar Git en andra commit som är identisk till ändringarna. Detta förorenar historiken och försvårar git bisect
• Förlust av sammanhang — cherry-pick överför diffen men inte informationen om föräldracommits och beroenden. Om cherry-pick tillämpade commit A utan commit B som A var beroende av kan logiska fel uppstå
• Konflikter vid merge — efter cherry-pick, vid fullständig sammanslagning av grenar, kan Git se samma ändringar två gånger och skapa konflikter som kunde ha undvikits vid vanlig merge
• Brist på samband — utan flaggan -x går det inte att förstå att en commit har överförts från en annan gren. Vid sökning efter ändringens ursprung kan utvecklaren spendera timmar på att fastställa commitens härkomst

Rekommendationer för att minimera risker: använd alltid flaggan -x för att ange ursprungligt SHA, dokumentera orsaken till cherry-pick i commit-meddelandet, och använd om möjligt merge istället för cherry-pick när sammanhanget tillåter. Om det blir många cherry-pick — överväg omstrukturering av grenar.

Automatisering av kontroller vid Cherry-pick

CI-pipelines bör betrakta cherry-pick som ett separat scenario. Det rekommenderas att ställa in automatisk kontroll: vid skapande av en cherry-pick-commit kontrollerar CI att de ändrade filerna motsvarar den förväntade uppsättningen och kör tester för de berörda modulerna. Detta minskar risken för regression vid punktöverföring av ändringar mellan grenar.