Cherry-pick: vad det är, hur cherry-pick utförs och Git-kommandon

Vad är cherry-pick i Git

Cherry-pick — är kommandot git cherry-pick som tar ändringar från en befintlig commit och tillämpar dem som en ny commit i den aktuella grenen. Den ursprungliga committen förblir på sin plats i sin egen gren medan en kopia av ändringarna skapas i målgrenen. Kommandot är användbart när du behöver överföra en specifik korrigering utan att flytta hela grenen.

Syntax: git cherry-pick <commit-hash>. Git analyserar skillnaden (diff) mellan den angivna committen och dess föregående och tillämpar denna skillnad på den aktuella grenen. Om ändringarna berör flera filer — överförs de alla tillsammans. Kommandot accepterar även intervall: git cherry-pick A..B — alla commits från A till B, exklusive A.

Flaggor utökar möjligheterna: -n (--no-commit) tillämpar ändringar i arbetskatalogen och indexet utan att skapa en commit — användbart när du behöver slå ihop ändringar från flera commits till en. Flaggan -x lägger till en rad (cherry picked from commit ...) i commit-meddelandet, vilket förenklar spårning av ändringars ursprung i historiken.

# Cherry-pick av en enskild commit med hash
git cherry-pick a1b2c3d

# Cherry-pick av flera commits (sekventiellt)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick utan automatisk commit
git cherry-pick -n a1b2c3d

# Flagga -x lägger till referens till ursprunglig commit
git cherry-pick -x a1b2c3d

När används cherry-pick

Huvudscenario — överföring av korrigeringar mellan releasesgrenar. Föreställ dig: i develop hittades och åtgärdades ett kritiskt fel. Releasesgrenen release/v2.1 är redan avskild och detta fel finns också i den. Merge av hela develop till release skulle föra med sig mycket ofärdig kod, medan cherry-pick av en enda commit med korrigeringen är en säker och precis lösning.

Andra scenariot — ångra ändringar (revert) med återställning. Om en commit har ångrats via git revert och det senare visar sig att ångringen var felaktig — återställer cherry-pick av den ångrade committen ändringarna. Detta är mer korrekt än att ångra reverten eftersom det inte skapar upprepade konflikter.

Tredje scenariot — sammanfoga commits från olika feature-grenar till en testgren för integrationstestning. Istället för att slå ihop flera ofärdiga grenar (med ofullständig kod) kan du välja endast färdiga commits från varje och testa deras samverkan.

• Bugfixar — överföring av korrigering från develop till release utan ofärdig kod.
• Hotfix — tillämpning av korrigering från hotfix-gren till main och develop samtidigt.
• Ångra felaktig revert — cherry-pick av den ångrade committen för att återställa ändringar.
• Testning — insamling av utvalda commits från olika grenar för integrationskontroll.

Cherry-pick vs rebase och merge

Cherry-pick skiljer sig från rebase och merge genom att det arbetar på nivån av enskilda commits, inte hela grenar. Medan rebase överför alla commits i en gren och merge slår samman två grenar, väljer cherry-pick endast de som behövs. Detta gör det till ett mer precist verktyg, men också mer manuellt.

En annan skillnad — författarskap. Vid cherry-pick behåller Git som standard författaren (Author) av den ursprungliga committen, men committer (Committer) blir den aktuella användaren. I commit-meddelandet kan ursprunget spåras via flaggan -x. Vid rebase är både författare och committer den aktuella användaren med ny hash.

Prestanda: cherry-pick av en commit är snabbare än merge av två grenar med många commits. Men om du behöver överföra dussintals commits är det bättre att skapa en temporär gren och utföra rebase — det är mer effektivt och kräver inte att man anger dussintals hash.

Överföring av flera commits

Flera commits kan överföras med ett enda kommando genom att lista deras hash med mellanslag: git cherry-pick A B C. Git tillämpar commits sekventiellt i angiven ordning. Om någon av commits orsakar en konflikt pausas cherry-pick och utvecklaren måste lösa konflikten, varefter hen kan fortsätta med kommandot git cherry-pick --continue.

Commit-intervall: git cherry-pick A..B (alla commits efter A till B, exklusive A) och git cherry-pick A^..B (alla commits från A inklusive till B). Intervall är praktiska när du behöver överföra alla commits från en gren utan föregåenderelation — till exempel vid överföring av en färdig funktion från en gammal gren till en ny.

Flaggan --strategy bestämmer hur Git ska tillämpa ändringarna. Som standard används recursive-strategin, men du kan ange ours eller theirs för automatisk val av konfliktsida. Flaggan --mainline används vid cherry-pick av en merge-commit — anger föregåendenumret (1 eller 2) relativt vilket diff beräknas.

# Cherry-pick av commit-intervall
git cherry-pick develop~5..develop~2

# Cherry-pick av merge-commit (ange föregående)
git cherry-pick -m 1 m9n0o1p

# Använd theirs-strategi
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Fortsätt efter konfliktlösning
git cherry-pick --continue

Konflikter vid cherry-pick

Konflikter vid cherry-pick uppstår när ändringarna i den överförda committen påverkar samma rader som har ändrats i målgrenen. Git pausar utförandet, markerar konflikterande filer och väntar på lösning. I status visas sådana filer som both modified.

Tillvägagångssätt vid konflikt: öppna den konflikterande filen, hitta konfliktmarkörerna (<<<<<<<, =======, >>>>>>>), redigera innehållet, ta bort markörerna, utför git add för de lösta filerna och kör git cherry-pick --continue. Om konflikten inte går att lösa — git cherry-pick --abort avbryter hela cherry-pick och återställer grenen till ursprungligt tillstånd.

Ett vanligt problem: committen innehåller redan ändringar som motsvarar befintliga. I detta fall rapporterar Git «nothing to commit» eller «empty commit» vid cherry-pick-försök. Flaggorna --keep-redundant-commits och --empty=keep tvingar Git att skapa en tom commit för att bevara sekvensen, medan --skip gör att en sådan commit hoppas över.

# Konflikt under cherry-pick — stoppa
git cherry-pick a1b2c3d
# error: could not apply a1b2c3d... commit message

# Lös konflikt → lägg till i index
git add src/conflicted_file.swift
git cherry-pick --continue

# Hoppa över tom commit (redan tillämpad)
git cherry-pick --skip

# Fullständig avbrytning
git cherry-pick --abort

Bästa praxis för cherry-pick

Första regeln: kontrollera alltid att den överförda committen är självständig. Om commit A är beroende av ändringar i commit B som inte överförs, kan cherry-pick av A bryta bygget. Före cherry-pick är det bra att kontrollera vilka filer committen ändrade via git show --stat <hash>.

Andra regeln: dokumentera cherry-pick. Använd flaggan -x så att commit-meddelandet innehåller en referens till den ursprungliga committen. Detta hjälper vid senare analys av historiken för att förstå var ändringen kom ifrån. Utan -x ser cherry-pick ut som en vanlig commit och dess ursprung kan endast fastställas via git log --graph.

Tredje regeln: undvik cherry-pick mellan grenar som divergerar för mycket. Om det har gått lång tid sedan committen skapades och kodbasen har förändrats avsevärt, kommer konflikterna att bli många och komplexa. I sådana fall är det bättre att göra korrigeringen på nytt i målgrenen — det tar mindre tid än att lösa dussintals konflikter.

• Cherry-pick endast självständiga commits utan externa beroenden.
• Flagga -x är obligatorisk för att dokumentera committens ursprung i meddelandet.
• Undvik cherry-pick av gamla commits med stor avvikelse i kodbasen.
• CI/CD kontrollera bygget efter cherry-pick: konflikt kan saknas men koden kanske inte kompilerar.
• Kommentar i PR när du skapar en pull request, ange vilka commits som överförts via cherry-pick.