git-cherry-pick(1): Skillnad mellan sidversioner
Admin (diskussion | bidrag) (Skapade sidan med '= git-cherry-pick(1) = == NAMN == git-cherry-pick - tillämpa ändringar som införts av befintliga incheckningar == SYNOPSIS == <pre> git cherry-pick [--edit] [-n] [-m <föräldranummer>] [-s] [-x] [--ff] [-S[<nyckel-id>]] <incheckning>... git cherry-pick (--continue | --skip | --abort | --quit) </pre> == BESKRIVNING == Givet en eller flera befintliga incheckningar tillämpar '''git cherry-pick''' den ändring som varje incheckning introducerar och...') |
Admin (diskussion | bidrag) |
||
| Rad 1: | Rad 1: | ||
== NAMN == | == NAMN == | ||
Nuvarande version från 27 maj 2026 kl. 09.14
NAMN
git-cherry-pick - tillämpa ändringar som införts av befintliga incheckningar
SYNOPSIS
git cherry-pick [--edit] [-n] [-m <föräldranummer>] [-s] [-x] [--ff]
[-S[<nyckel-id>]] <incheckning>...
git cherry-pick (--continue | --skip | --abort | --quit)
BESKRIVNING
Givet en eller flera befintliga incheckningar tillämpar git cherry-pick den ändring som varje incheckning introducerar och skapar en ny incheckning för varje sådan ändring. Detta kräver att arbetskatalogen är ren, det vill säga att det inte finns några ändringar jämfört med HEAD-incheckningen.
När det inte är uppenbart hur en ändring ska tillämpas händer följande:
- Den aktuella grenen och HEAD-pekaren ligger kvar på den senaste incheckning som kunde skapas framgångsrikt.
- Referensen CHERRY_PICK_HEAD sätts till den incheckning som introducerade ändringen som inte kunde tillämpas utan problem.
- Sökvägar där ändringen kunde tillämpas rent uppdateras både i indexfilen och i arbetskatalogen.
- För sökvägar med konflikt lagrar indexfilen upp till tre versioner, enligt beskrivningen i avsnittet ”SANN SAMMANFOGNING” i git-merge(1). Filerna i arbetskatalogen innehåller en beskrivning av konflikten markerad med de vanliga konfliktmarkörerna <<<<<<< och >>>>>>>.
- Inga andra ändringar görs.
Se git-merge(1) för råd om hur sådana konflikter kan lösas.
ALTERNATIV
<incheckning>...
- Incheckningar som ska cherry-pickas. För en mer fullständig lista över sätt att ange incheckningar, se gitrevisions(7). Uppsättningar av incheckningar kan anges, men ingen genomgång görs som standard, som om alternativet --no-walk hade angetts; se git-rev-list(1). Observera att om ett intervall anges matas alla argument i <incheckning>... till en enda revisionsvandring; se det senare exemplet som använder maint master..next.
-e, --edit
- Med detta alternativ låter git cherry-pick dig redigera incheckningsmeddelandet innan incheckningen skapas.
--cleanup=<läge>
- Detta alternativ avgör hur incheckningsmeddelandet ska rensas innan det skickas vidare till incheckningsmaskineriet. Se git-commit(1) för mer information. Om <läge> särskilt ges värdet scissors läggs saxmarkeringar till i MERGE_MSG innan meddelandet skickas vidare vid en konflikt.
-x
- När incheckningen skapas läggs en rad till i det ursprungliga incheckningsmeddelandet som anger ”(cherry picked from commit ...)”, för att visa vilken incheckning ändringen cherry-pickades från. Detta görs endast för cherry-pick utan konflikter. Använd inte detta alternativ när du cherry-pickar från en privat gren, eftersom informationen är oanvändbar för mottagaren. Om du däremot cherry-pickar mellan två publikt synliga grenar, till exempel när du backportar en fix till en underhållsgren för en äldre version från en utvecklingsgren, kan informationen vara användbar.
-r
- Tidigare var standardbeteendet för kommandot att använda -x enligt ovan, och -r användes för att stänga av det. Numera är standard att inte använda -x, så detta alternativ gör ingenting.
-m <föräldranummer>, --mainline <föräldranummer>
- Normalt kan du inte cherry-picka en sammanfogningsincheckning eftersom du inte vet vilken sida av sammanfogningen som ska betraktas som huvudlinjen. Detta alternativ anger föräldranumret, med början från 1, för huvudlinjen och låter cherry-pick spela upp ändringen relativt den angivna föräldern.
-n, --no-commit
- Vanligtvis skapar kommandot automatiskt en följd av incheckningar. Denna flagga tillämpar de ändringar som krävs för att cherry-picka varje namngiven incheckning på arbetskatalogen och indexet, utan att skapa någon incheckning. När detta alternativ används behöver dessutom indexet inte matcha HEAD-incheckningen. Cherry-pickningen görs mot indexets starttillstånd.
- Detta är användbart när du vill cherry-picka effekten av flera incheckningar till indexet i rad.
-s, --signoff
- Lägg till en Signed-off-by-rad i slutet av incheckningsmeddelandet. Se alternativet signoff i git-commit(1) för mer information.
-S[<nyckel-id>], --gpg-sign[=<nyckel-id>], --no-gpg-sign
- GPG-signera incheckningar. Argumentet nyckel-id är valfritt och använder som standard incheckarens identitet. Om det anges måste det sitta direkt ihop med alternativet utan mellanslag. --no-gpg-sign är användbart för att upphäva både konfigurationsvariabeln commit.gpgSign och ett tidigare --gpg-sign.
--ff
- Om aktuell HEAD är samma som föräldern till incheckningen som cherry-pickas görs en snabbspolning till denna incheckning.
--allow-empty
- Som standard misslyckas cherry-pickning av en tom incheckning och anger att en uttrycklig körning av git commit --allow-empty krävs. Detta alternativ åsidosätter beteendet och låter tomma incheckningar bevaras automatiskt vid cherry-pick. Observera att när --ff används bevaras tomma incheckningar som uppfyller snabbspolningskravet även utan detta alternativ. Observera också att detta alternativ endast bevarar incheckningar som var tomma från början, det vill säga incheckningar som lagrade samma träd som sin förälder. Incheckningar som blir tomma på grund av en tidigare incheckning gör att cherry-pickningen misslyckas. För att tvinga med sådana incheckningar, använd --empty=keep.
--allow-empty-message
- Som standard misslyckas cherry-pickning av en incheckning med tomt meddelande. Detta alternativ åsidosätter beteendet och låter incheckningar med tomma meddelanden cherry-pickas.
--empty=(drop|keep|stop)
- Anger hur incheckningar som cherry-pickas och som är redundanta med ändringar som redan finns i den aktuella historiken ska hanteras.
- drop
- Incheckningen tas bort.
- keep
- Incheckningen behålls. Implicerar --allow-empty.
- stop
- Cherry-pickningen stannar när incheckningen tillämpas, så att du kan undersöka incheckningen. Detta är standardbeteendet.
- Observera att --empty=drop och --empty=stop endast anger hur en incheckning som inte var tom från början, men som blev tom på grund av en tidigare incheckning, ska hanteras. Incheckningar som var tomma från början gör fortfarande att cherry-pickningen misslyckas om inte något av --empty=keep eller --allow-empty anges.
--keep-redundant-commits
- Föråldrad synonym för --empty=keep.
--strategy=<strategi>
- Använd den angivna sammanfogningsstrategin. Bör endast användas en gång. Se avsnittet ”SAMMANFOGNINGSSTRATEGIER” i git-merge(1) för detaljer.
-X<alternativ>, --strategy-option=<alternativ>
- Skicka ett strategispecifikt alternativ vidare till sammanfogningsstrategin. Se git-merge(1) för detaljer.
--rerere-autoupdate, --no-rerere-autoupdate
- Efter att rerere-mekanismen har återanvänt en lagrad lösning för den aktuella konflikten för att uppdatera filerna i arbetskatalogen, tillåt den även att uppdatera indexet med resultatet av lösningen. --no-rerere-autoupdate är ett bra sätt att dubbelkontrollera vad git-rerere(1) gjorde och fånga möjliga felaktiga sammanfogningar innan resultatet förs in i indexet med ett separat git-add(1).
SEKVENSSUBKOMMANDON
--continue
- Fortsätt den pågående operationen med hjälp av informationen i .git/sequencer. Detta kan användas för att fortsätta efter att konflikter i en misslyckad cherry-pick eller revert har lösts.
--skip
- Hoppa över den aktuella incheckningen och fortsätt med resten av sekvensen.
--quit
- Glöm den pågående operationen. Detta kan användas för att rensa sekvenserarens tillstånd efter en misslyckad cherry-pick eller revert.
--abort
- Avbryt operationen och återgå till tillståndet före sekvensen.
EXEMPEL
git cherry-pick master
Tillämpa ändringen som introducerades av incheckningen längst ut på grenen master och skapa en ny incheckning med denna ändring.
git cherry-pick ..master git cherry-pick ^HEAD master
Tillämpa ändringarna som introducerats av alla incheckningar som är förfäder till master men inte till HEAD, och skapa nya incheckningar.
git cherry-pick maint next ^master git cherry-pick maint master..next
Tillämpa ändringarna som introducerats av alla incheckningar som är förfäder till maint eller next, men inte till master eller någon av dess förfäder. Observera att det senare inte betyder maint och allt mellan master och next; mer specifikt används maint inte om den ingår i master.
git cherry-pick master~4 master~2
Tillämpa ändringarna som introducerades av den femte respektive tredje senaste incheckningen som master pekar på, och skapa två nya incheckningar med dessa ändringar.
git cherry-pick -n master~1 next
Tillämpa ändringarna som introducerades av den näst senaste incheckningen som master pekar på och av den senaste incheckningen som next pekar på i arbetskatalogen och indexet, men skapa inga incheckningar med dessa ändringar.
git cherry-pick --ff ..next
Om historiken är linjär och HEAD är en förfader till next, uppdateras arbetskatalogen och HEAD-pekaren flyttas fram så att den matchar next. Annars tillämpas ändringarna som introducerats av de incheckningar som finns i next men inte i HEAD på den aktuella grenen, och en ny incheckning skapas för varje ny ändring.
git rev-list --reverse master -- README | git cherry-pick -n --stdin
Tillämpa ändringarna som introducerats av alla incheckningar på grenen master som rörde README på arbetskatalogen och indexet, så att resultatet kan granskas och göras till en enda ny incheckning om det är lämpligt.
Följande sekvens försöker backporta en patch, avbryter eftersom koden som patchen ska tillämpas på har förändrats för mycket, och försöker sedan igen, denna gång med större omsorg kring matchning av kontextrader.
$ git cherry-pick topic^ (1) $ git diff (2) $ git cherry-pick --abort (3) $ git cherry-pick -Xpatience topic^ (4)
- Tillämpa ändringen som skulle visas av git show topic^. I detta exempel kan patchen inte tillämpas rent, så information om konflikten skrivs till indexet och arbetskatalogen och ingen ny incheckning skapas.
- Sammanfatta ändringar som behöver förenas.
- Avbryt cherry-pickningen. Med andra ord: återgå till tillståndet före cherry-pickningen, samtidigt som eventuella lokala ändringar du hade i arbetskatalogen bevaras.
- Försök tillämpa ändringen som introducerades av topic^ igen, men lägg extra tid på att undvika misstag som beror på felaktigt matchade kontextrader.
SE ÄVEN
GIT
Del av git(1)-sviten.
COLOPHON
Denna sida är en del av projektet git (Git distributed version control system). Information om projektet finns på http://git-scm.com/. Om du har en felrapport för denna manualsida, se http://git-scm.com/community. Denna sida hämtades från projektets uppströms Git-arkiv på https://github.com/git/git.git den 2026-05-24. Vid den tidpunkten var datumet för den senaste incheckningen som hittades i arkivet 2026-05-22. Om du upptäcker renderingsproblem i denna HTML-version av sidan, eller om du anser att det finns en bättre eller mer aktuell källa för sidan, eller om du har rättelser eller förbättringar av informationen i denna COLOPHON, som inte är en del av den ursprungliga manualsidan, skicka e-post till man-pages@man7.org.
SIDOR SOM HÄNVISAR TILL DENNA SIDA
Sidslut
Orginalhemsidan på Engelska https://man7.org/linux/man-pages/man1/git-cherry-pick.1.html
Det här är en maskinöversättning av Linux man sidor till svenska. Om du hittar fel är vi tacksamma om du rapporterar dem via formuläret som finns på
https://www.linux.se/kontaka-linux-se/
Tack till Datorhjälp hemma som har sponsrat Linux.se med webbhotell.