Incheckningar som ska plockas som russin ur kakan. För en mer komplett lista över sätt att ange incheckningar, se gitrevisions[7]. Uppsättningar av incheckningar kan skickas men ingen genomgång görs som standard, som om alternativet --no-walk hade angetts, se git-rev-list[1]. Observera att om man anger ett intervall matas alla <inchecknings>…​-argument till en enda revisionsgenomgång (se ett senare exempel som använder maint master..next).

Med det här alternativet, låter git cherry-pick dig redigera incheckningsmeddelandet innan incheckningen.

Det här alternativet avgör hur incheckningsmeddelandet ska rensas innan det skickas vidare till incheckningsmaskineriet. Se git-commit[1] för mer information. Om <läge> ges värdet scissors kommer scissors att läggas till i MERGE_MSG innan det skickas vidare i händelse av en konflikt.

När incheckningen registreras, lägg till en rad som säger "(cherry picked from commit …​)" i det ursprungliga incheckningsmeddelandet för att ange från vilken incheckning denna ändring handplockades. Detta görs endast för handplockningar utan konflikter. Använd inte alternativet om du handplockar från en privat gren, eftersom informationen då är värdelös för mottagaren. Om du däremot handplockar mellan två offentligt synliga grenar (t.ex. bakporterar en fix till en underhållsgren för en äldre utgåva från en utvecklingsgren) kan denna information vara användbar.

Tidigare var det så att kommandot som standard gjorde -x som beskrivits ovan, och -r var för att inaktivera det. Nu är standardinställningen att inte göra -x så detta är en verkningslös flagga.

Vanligtvis kan du inte handplocka en sammanslagning eftersom det inte går att avgöra vilken sida av sammanslagningen som ska betraktas som huvudlinjen. Det här alternativet anger huvudlinjens föräldernummer (med början på 1) och låter handplockning återspela ändringen relativt den angivna föräldern.

Vanligtvis skapar kommandot automatiskt en sekvens av incheckningar. Denna flagga tillämpar de ändringar som krävs för att välja ut varje namngiven incheckning till ditt arbetsträd och indexet, utan att göra någon incheckning. Dessutom, när detta alternativ används, behöver ditt index inte matcha HEAD-incheckningen. Urvalet görs mot starttillståndet för ditt index.

Lägg till en Signed-off-by-slutrad i slutet av incheckningsmeddelandet. Se signoff-alternativet i git-commit[1] för mer information.

GPG-signera incheckningar. Argumentet nyckelid är valfritt och används som standard för incheckaridentiteten; om det anges måste det fästas vid alternativet utan mellanslag. --no-gpg-sign är användbart för att åsidosätta både konfigurationsvariabeln commit.gpgSign och tidigare --gpg-sign.

Om den aktuella HEAD är densamma som föräldern till den cherry-pick:ade incheckningen, kommer en snabbspolning till denna incheckning att utföras.

Som standard misslyckas handplockning av en tom incheckning, vilket innebär att ett uttryckligt anrop av git commit --allow-empty krävs. Det här alternativet åsidosätter det beteendet och gör att tomma incheckningar bevaras automatiskt vid handplockning. Observera att när "--ff" gäller behålls tomma incheckningar som uppfyller kravet för snabbspolning även utan detta alternativ. Observera också att alternativet endast behåller incheckningar som ursprungligen var tomma (d.v.s. incheckningen registrerade samma träd som sin förälder). Incheckningar som blir tomma på grund av en tidigare incheckning gör att handplockningen misslyckas. Använd --empty=keep för att tvinga med sådana incheckningar.

Som standard misslyckas handplockning av en incheckning med tomt meddelande. Det här alternativet åsidosätter det beteendet och tillåter att incheckningar med tomma meddelanden handplockas.

Hur incheckningar som handplockas och är redundanta med ändringar som redan finns i den aktuella historiken ska hanteras.

Föråldrad synonym för --empty=keep.

Använd den givna sammanslagningsstrategin. Bör endast användas en gång. Se avsnittet SAMMANSLAGNINGSSTRATEGIER i git-merge[1] för mer information.

Skicka det merge-strategispecifika alternativet vidare till merge-strategin. Se git-merge[1] för mer information.

Efter att rerere-mekanismen återanvänder en inspelad lösning på 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 dubbelkolla vad rerere gjorde och upptäcka potentiella felaktiga sammanslagningar, innan resultatet sparas i indexet med ett separat git add.

Fortsätt den pågående operationen med informationen i .git/sequencer. Kan användas för att fortsätta efter att konflikter i en misslyckad cherry-picking eller ångring har lösts.

Hoppa över den nuvarande incheckningen och fortsätt med resten av sekvensen.

Glöm den pågående operationen. Kan användas för att rensa sequencerns tillstånd efter en misslyckad cherry pick eller återställning.

Avbryt åtgärden och återgå till försekvenstillståndet.

Tillämpa ändringen som introducerades av incheckningen i toppen på master-grenen och skapa en ny incheckning med denna ändring.

Tillämpa ändringarna som introducerats av alla incheckningar som är föregångare till master men inte till HEAD för att skapa nya incheckningar.

Tillämpa ändringarna som introduceras av alla incheckningar som är föregångare till maint eller next, men inte master eller någon av dess föregångare. Observera att det senare inte betyder maint och allt mellan master och next; specifikt kommer maint inte att användas om det ingår i master.

Tillämpa ändringarna som introducerades av den femte och tredje sista incheckningarna som master pekar på och skapa 2 nya incheckningar med dessa ändringar.

Tillämpa på arbetsträdet och indexet de ändringar som introducerades av den näst sista incheckningen som pekas ut av master och av den sista incheckningen som pekas ut av next, men skapa ingen incheckning med dessa ändringar.

Om historiken är linjär och HEAD är en förfader till next, uppdatera arbetsträdet och flytta HEAD-pekaren så att den matchar next. Annars tillämpar du ändringarna som introducerats av de incheckningar som finns i next men inte HEAD på den aktuella grenen, och skapar en ny incheckning för varje ny ändring.

Tillämpa ändringarna som introducerats av alla incheckningar på huvudgrenen som berörde README på arbetsträdet och indexet, så att resultatet kan inspekteras och göras om till en enda ny incheckning om det är lämpligt.