git cherry-pick bruker en spesifikk commit fra en gren på en annen gren — og kopierer bare endringene fra den commiten, uten å flette hele grenen. Det er nyttig for selektivt å bruke bestemte endringer, som å tilbakeføre en fiks.
# 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 tar endringene fra en spesifikk commit og bruker dem som en ny commit på din nåværende gren — selektivt, uten å ta med resten av kildegrenen.
✓ 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.
Å forstå git cherry-pick er verdifullt for selektivt å bruke spesifikke endringer, en nyttig evne for bestemte situasjoner, så det er praktisk Git-kunnskap som er verdt å kunne.
Kjernefunksjonen — å bruke bare en spesifikk commits endringer på en annen gren uten å flette hele grenen — løser faktiske behov som sammenslåing ikke kan håndtere på en ryddig måte.
Den vanligste og viktigste bruken er tilbakeføring: å bruke en spesifikk fiks fra hovedgrenen til en utgivelses- eller vedlikeholdsgren, og få bare den fiksen uten å slå sammen alle hovedgrens andre (muligens ustabile eller uutgitte) endringer til utgivelsesgrrenen — et hyppig behov når man vedlikeholder utgitt programvare.
Andre brukstilfeller inkluderer å bruke en enkelt ferdig commit mens resten av dens gren ikke er klar, å flytte en commit laget på feil gren til den riktige, og selektivt å hente inn en enkelt endring.
Å forstå forsiktighetsreglene er viktig for å bruke cherry-pick på passende måte: det lager duplikatcommits (de samme endringene med forskjellige hasher på hver gren), noe som kan forårsake forvirring eller konflikter hvis grenene senere slåes sammen, så det bør brukes bevisst for selektive behov i stedet for som en rutineintegreringsmetode (merge eller rebase er bedre for å integrere hele grener), og å cherry-picke mange commits er et tegn på at du sannsynligvis vil ha en merge i stedet.
Denne vurderingen — å bruke cherry-pick for spesifikke, selektive situasjoner (spesielt tilbakeføring) mens du foretrekker merge/rebase for rutineintegrasjon — reflekterer god Git-praksis.
Siden selektivt å bruke spesifikke endringer (spesielt å tilbakeføre fiksinger til utgivelsesgre ner) er et reelt, av og til viktig behov, og siden cherry-pick er verktøyet for det (med forsiktighetsregler om dens passende bruk), er det verdifullt, praktisk relevant Git-kunnskap å forstå git cherry-pick — hvordan det fungerer, dets viktige brukstilfeller som tilbakeføring, og når du skal bruke det kontra merge/rebase — for å håndtere de selektive-endringssituasjonene som oppstår når du vedlikeholder og administrerer programvare på tvers av grener.