git cherry-pick anvender et specifikt commit fra én branch på en anden — kopierer blot dette commits ændringer, uden at merge hele branchen. Det er nyttigt til at anvende særlige ændringer selektivt, som f.eks. at backporte en fejlrettelse.
# apply a specific commit from another branch onto the current branch
git cherry-pick <commit-hash>
git cherry-pick <commit1> <commit2>
git cherry-pick A..B
Cherry-pick tager ændringerne fra et specifikt commit og anvender dem som et nyt commit på din nuværende branch — selektivt, uden at bringe resten af kildebranchen med.
✓ BACKPORTING a fix — apply a bug fix from main to a release/maintenance branch
(without merging all of main's other changes into the release branch)
✓ Applying a specific commit that's ready, while the rest of its branch isn't
✓ Moving a commit made on the wrong branch to the correct one
✓ Selectively pulling one change from another branch
⚠️ Creates DUPLICATE commits (same changes, different hashes on each branch):
→ can cause confusion/conflicts if branches are later merged (the change appears twice,
though Git often handles it). Prefer merge/rebase for integrating whole branches.
⚠️ Cherry-picking many commits is a sign you might want a merge/rebase instead
⚠️ Conflicts can occur (resolve like a merge); use it deliberately, not as a default
→ Use cherry-pick for SELECTIVE, specific needs — not routine integration.
At forstå git cherry-pick er værdifuldt for at anvende specifikke ændringer selektivt, en nyttig mulighed for bestemte situationer, så det er praktisk Git-viden værd at kende.
Kernefunktionen — at anvende blot et specifikt commits ændringer på en anden branch uden at merge hele branchen — løser virkelige behov, som merge ikke kan håndtere pænt.
Den mest almindelige og vigtige brug er backporting: at anvende en specifik fejlrettelse fra mainbranchen på en release- eller maintenance-branch, og få blot den rettelse uden at merge alle andre (muligvis ustabile eller ulancerede) ændringer fra main ind i release-branchen — et hyppigt behov ved vedligeholdelse af frigivet software.
Andre anvendelser inkluderer at anvende et enkelt parat commit mens resten af dets branch ikke er parat, at flytte et commit der blev lavet på den forkerte branch til den rigtige, og at trække en enkelt ændring selektivt.
At forstå forsigtighedsreglerne er vigtig for at bruge cherry-pick på passende vis: det opretter duplikerede commits (de samme ændringer med forskellige hashes på hver branch), hvilket kan forårsage forvirring eller konflikter, hvis brancherne senere merges, så det skal bruges målrettet til selektive behov i stedet for som en rutineintegrationsmetode (merge eller rebase er bedre til at integrere hele branches), og cherry-picking mange commits er tegnet på, at du sandsynligvis gerne vil have et merge i stedet.
Denne vurdering — at bruge cherry-pick til specifikke, selektive situationer (især backporting) mens man foretrækker merge/rebase til rutineintegration — afspejler god Git-praksis.
Da det at anvende specifikke ændringer selektivt (især at backporte rettelser til release-branches) er et virkelig, lejlighedsvis vigtigt behov, og da cherry-pick er værktøjet til det (med forsigtighedsregler om dets hensigtsmæssige brug), er det værdifuldt, praktisk relevant Git-viden at forstå git cherry-pick — hvordan det fungerer, dets vigtigste use cases som backporting, og hvornår man skal bruge det versus merge/rebase — for at håndtere de selektive-ændring-scenarier, der opstår ved vedligeholdelse og styring af software på tværs af branches.