English ▾ Themen ▾ Neueste Version ▾ git-cherry-pick zuletzt aktualisiert in 2.50.0

NAME

git-cherry-pick - Wende die von bestehenden Commits eingeführten Änderungen an

SYNOPSIS

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff]
		  [-S[<keyid>]] <commit>…​
git cherry-pick (--continue | --skip | --abort | --quit)

BESCHREIBUNG

Wende für einen oder mehrere bestehende Commits die von jedem einzelnen eingeführte Änderung an und erstelle für jede davon einen neuen Commit. Dies setzt voraus, dass dein Arbeitsbaum sauber ist (keine Änderungen gegenüber dem HEAD-Commit).

Wenn es nicht offensichtlich ist, wie eine Änderung angewendet werden soll, geschieht Folgendes:

  1. Der aktuelle Branch und der HEAD-Zeiger bleiben beim letzten erfolgreich erstellten Commit.

  2. Der Referenz-Zeiger CHERRY_PICK_HEAD wird so gesetzt, dass er auf den Commit zeigt, der die schwer anzuwendende Änderung eingeführt hat.

  3. Pfade, auf denen die Änderung sauber angewendet wurde, werden sowohl in der Indexdatei als auch in deinem Arbeitsbaum aktualisiert.

  4. Für konfliktbehaftete Pfade zeichnet die Indexdatei bis zu drei Versionen auf, wie im Abschnitt "WAHRER MERGE" von git-merge[1] beschrieben. Die Arbeitsbaumdateien enthalten eine Beschreibung des Konflikts, die von den üblichen Konfliktmarkern <<<<<<< und >>>>>>> umschlossen ist.

  5. Keine weiteren Änderungen werden vorgenommen.

Siehe git-merge[1] für einige Hinweise zur Auflösung solcher Konflikte.

OPTIONEN

<commit>…

Zu cherry-pickende Commits. Eine vollständigere Liste der Möglichkeiten, Commits zu benennen, findest du unter gitrevisions[7]. Mengen von Commits können übergeben werden, aber standardmäßig wird keine Traversierung durchgeführt, als ob die Option --no-walk angegeben wäre; siehe git-rev-list[1]. Beachte, dass die Angabe eines Bereichs alle <commit>…-Argumente an einen einzelnen Revisionsdurchlauf übergibt (siehe ein späteres Beispiel, das maint master..next verwendet).

-e
--edit

Mit dieser Option lässt dich git cherry-pick die Commit-Nachricht vor dem Committen bearbeiten.

--cleanup=<mode>

Diese Option bestimmt, wie die Commit-Nachricht bereinigt wird, bevor sie an die Commit-Mechanismen weitergegeben wird. Siehe git-commit[1] für weitere Details. Insbesondere, wenn dem <mode> ein Wert von scissors zugewiesen wird, werden Scheren an MERGE_MSG angehängt, bevor sie im Falle eines Konflikts weitergegeben werden.

-x

Beim Aufzeichnen des Commits wird eine Zeile angehängt, die "(cherry picked from commit …​)" lautet, an die ursprüngliche Commit-Nachricht, um anzugeben, von welchem Commit diese Änderung per Cherry-Pick übernommen wurde. Dies geschieht nur für Cherry-Picks ohne Konflikte. Verwende diese Option nicht, wenn du von deinem privaten Branch per Cherry-Pick übernimmst, da die Informationen für den Empfänger nutzlos sind. Wenn du hingegen von zwei öffentlich sichtbaren Branches per Cherry-Pick übernimmst (z. B. ein Fix für einen Wartungs-Branch für eine ältere Version von einem Entwicklungs-Branch zurückportierst), können diese Informationen nützlich sein.

-r

Früher war es so, dass der Befehl standardmäßig -x ausführte, wie oben beschrieben, und -r diente dazu, dies zu deaktivieren. Jetzt ist der Standard, dass -x nicht ausgeführt wird, sodass diese Option keine Wirkung hat.

-m <parent-number>
--mainline <parent-number>

Normalerweise kannst du keinen Merge per Cherry-Pick übernehmen, da du nicht weißt, welche Seite des Merges als Hauptlinie betrachtet werden soll. Diese Option gibt die Elternnummer (beginnend bei 1) der Hauptlinie an und ermöglicht es cherry-pick, die Änderung relativ zum angegebenen Elternteil erneut anzuwenden.

-n
--no-commit

Normalerweise erstellt der Befehl automatisch eine Sequenz von Commits. Dieses Flag wendet die zum Cherry-Picking jedes benannten Commits erforderlichen Änderungen auf deinen Arbeitsbaum und den Index an, ohne einen Commit zu erstellen. Darüber hinaus muss bei Verwendung dieser Option dein Index nicht mit dem HEAD-Commit übereinstimmen. Das Cherry-Picking erfolgt gegen den Anfangszustand deines Index.

Dies ist nützlich, wenn du die Auswirkungen von mehr als einem Commit nacheinander auf deinen Index per Cherry-Pick übernehmen möchtest.

-s
--signoff

Fügt am Ende der Commit-Nachricht einen Signed-off-by-Trailer hinzu. Siehe die Option signoff in git-commit[1] für weitere Informationen.

-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign

GPG-sign Commits. Das Argument keyid ist optional und standardmäßig die Committer-Identität; wenn es angegeben wird, muss es ohne Leerzeichen an die Option angehängt werden. --no-gpg-sign ist nützlich, um sowohl die Konfigurationsvariable commit.gpgSign als auch einen früheren Befehl --gpg-sign zu überschreiben.

--ff

Wenn der aktuelle HEAD mit dem Elternteil des per Cherry-Pick übernommenen Commits übereinstimmt, wird ein Fast-Forward zu diesem Commit durchgeführt.

--allow-empty

Standardmäßig schlägt das Cherry-Picking eines leeren Commits fehl, was darauf hinweist, dass ein expliziter Aufruf von git commit --allow-empty erforderlich ist. Diese Option überschreibt dieses Verhalten und erlaubt die automatische Beibehaltung leerer Commits bei einem Cherry-Pick. Beachte, dass bei aktivierter Option "--ff" leere Commits, die die "Fast-Forward"-Anforderung erfüllen, auch ohne diese Option beibehalten werden. Beachte auch, dass die Verwendung dieser Option nur ursprünglich leere Commits beibehält (d. h. der Commit hat denselben Baum wie sein Elternteil aufgezeichnet). Commits, die aufgrund eines vorherigen Commits leer werden, führen dazu, dass das Cherry-Picking fehlschlägt. Um die Einbeziehung dieser Commits zu erzwingen, verwende --empty=keep.

--allow-empty-message

Standardmäßig schlägt das Cherry-Picking eines Commits mit einer leeren Nachricht fehl. Diese Option überschreibt dieses Verhalten und erlaubt das Cherry-Picking von Commits mit leeren Nachrichten.

--empty=(drop|keep|stop)

Wie mit Commits umgegangen werden soll, die per Cherry-Pick übernommen werden und redundant zu bereits vorhandenen Änderungen in der aktuellen Historie sind.

drop

Der Commit wird verworfen.

keep

Der Commit wird beibehalten. Impliziert --allow-empty.

stop

Das Cherry-Picking stoppt, wenn der Commit angewendet wird, und erlaubt dir, den Commit zu überprüfen. Dies ist das Standardverhalten.

Beachte, dass --empty=drop und --empty=stop nur angeben, wie mit einem Commit umgegangen werden soll, der nicht ursprünglich leer war, sondern durch einen vorherigen Commit leer geworden ist. Commits, die ursprünglich leer waren, führen weiterhin dazu, dass das Cherry-Picking fehlschlägt, es sei denn, eine der Optionen --empty=keep oder --allow-empty wird angegeben.

--keep-redundant-commits

Veraltete Synonym für --empty=keep.

--strategy=<strategy>

Verwendet die angegebene Merge-Strategie. Sollte nur einmal verwendet werden. Siehe den Abschnitt MERGE-STRATEGIEN in git-merge[1] für Details.

-X<option>
--strategy-option=<option>

Übergibt die strategie-spezifische Merge-Option an die Merge-Strategie. Details finden Sie in git-merge[1].

--rerere-autoupdate
--no-rerere-autoupdate

Nachdem der rerere-Mechanismus eine aufgezeichnete Auflösung für den aktuellen Konflikt wiederverwendet hat, um die Dateien im Arbeitsbaum zu aktualisieren, erlauben Sie ihm auch, den Index mit dem Ergebnis der Auflösung zu aktualisieren. --no-rerere-autoupdate ist eine gute Möglichkeit, zu überprüfen, was rerere getan hat, und potenzielle Fehlmerges zu erkennen, bevor das Ergebnis mit einem separaten git add in den Index übernommen wird.

SEQUENCER-UNTERBEFEHLE

--continue

Führe die laufende Operation mit den Informationen in .git/sequencer fort. Kann verwendet werden, um nach der Auflösung von Konflikten bei einem fehlgeschlagenen Cherry-Pick oder Revert fortzufahren.

--skip

Überspringe den aktuellen Commit und fahre mit dem Rest der Sequenz fort.

--quit

Vergiss die aktuelle laufende Operation. Kann verwendet werden, um den Sequenzer-Status nach einem fehlgeschlagenen Cherry-Pick oder Revert zu löschen.

--abort

Brich die Operation ab und kehre zum Zustand vor der Sequenz zurück.

BEISPIELE

git cherry-pick master

Wende die von dem Commit an der Spitze des master-Branches eingeführte Änderung an und erstelle einen neuen Commit mit dieser Änderung.

git cherry-pick ..master
git cherry-pick ^HEAD master

Wende die von allen Commits, die Vorfahren von master, aber nicht von HEAD sind, eingeführten Änderungen an, um neue Commits zu erstellen.

git cherry-pick maint next ^master
git cherry-pick maint master..next

Wende die von allen Commits, die Vorfahren von maint oder next sind, aber nicht von master oder einem seiner Vorfahren, eingeführten Änderungen an, um neue Commits für jede neue Änderung zu erstellen. Beachte, dass letzteres nicht maint und alles dazwischen master und next bedeutet; insbesondere wird maint nicht verwendet, wenn es in master enthalten ist.

git cherry-pick master~4 master~2

Wende die von den fünften und dritten letzten Commits, auf die master zeigt, eingeführten Änderungen an und erstelle 2 neue Commits mit diesen Änderungen.

git cherry-pick -n master~1 next

Wende die von dem vorletzten Commit, auf den master zeigt, und von dem letzten Commit, auf den next zeigt, eingeführten Änderungen auf den Arbeitsbaum und den Index an, aber erstelle keine Commits mit diesen Änderungen.

git cherry-pick --ff ..next

Wenn die Historie linear ist und HEAD ein Vorfahre von next ist, aktualisiere den Arbeitsbaum und bewege den HEAD-Zeiger, um next zu entsprechen. Andernfalls wende die von den Commits, die in next, aber nicht in HEAD sind, eingeführten Änderungen auf den aktuellen Branch an und erstelle für jede neue Änderung einen neuen Commit.

git rev-list --reverse master -- README | git cherry-pick -n --stdin

Wende die von allen Commits auf dem master-Branch, die README betrafen, eingeführten Änderungen auf den Arbeitsbaum und den Index an, sodass das Ergebnis überprüft und gegebenenfalls zu einem einzigen neuen Commit zusammengefasst werden kann.

Die folgende Sequenz versucht, einen Patch zurückzuportieren, schlägt fehl, weil der Code, auf den der Patch angewendet wird, zu stark verändert wurde, und versucht es dann erneut, diesmal mit größerer Sorgfalt beim Abgleichen von Kontextzeilen.

$ git cherry-pick topic^             (1)
$ git diff                           (2)
$ git cherry-pick --abort            (3)
$ git cherry-pick -Xpatience topic^  (4)

  1. Wende die Änderung an, die von git show topic^ angezeigt würde. In diesem Beispiel lässt sich der Patch nicht sauber anwenden, sodass Informationen über den Konflikt in den Index und den Arbeitsbaum geschrieben werden und kein neuer Commit daraus resultiert.

  2. Zusammenfassen der zu abgleichenden Änderungen

  3. Brich den Cherry-Pick ab. Mit anderen Worten, kehre zum Zustand vor dem Cherry-Pick zurück und behalte alle lokalen Änderungen bei, die du im Arbeitsbaum hattest.

  4. Versuche, die von topic^ eingeführte Änderung erneut anzuwenden, und nimm dir zusätzliche Zeit, um Fehler aufgrund von falsch übereinstimmenden Kontextzeilen zu vermeiden.

SIEHE AUCH

git-revert[1]

GIT

Teil der git[1] Suite