git cherry-pick

Branches und Merges

Änderungen bestimmter Commits auf den aktuellen Branch anwenden

Der Befehl 'git cherry-pick' wendet die Änderungen eines oder mehrerer vorhandener Commits auf den aktuellen Branch an und erzeugt für jeden einen neuen Commit. Anders als merge oder rebase, die mit ganzen Branches arbeiten, kopiert cherry-pick gezielt einzelne Commits. Das ist unbezahlbar, um Hotfixes auf Release-Branches zurückzuportieren, verlorene Commits zu retten oder bestimmte Features von einem Branch auf einen anderen zu bringen, ohne alles zu mergen. Jeder cherry-gepickte Commit bekommt einen neuen SHA – es ist eine Kopie, kein Verschieben. Cherry-pick arbeitet chirurgisch präzise und gibt dir feine Kontrolle darüber, welche Änderungen auf deinem Branch landen.

Syntax

git cherry-pick [--edit] [-n] [-m <parent-number>] [-s] [-x] [--ff] [-S[<keyid>]] <commit>...
git cherry-pick (--continue | --skip | --abort | --quit)
[ ] optional| oder<arg> Platzhalter... wiederholbar--flag Option

Optionen

Klicke auf eine Option, um sie aufzuklappen

Einsteiger (2)

Änderungen auf Arbeitsverzeichnis und Index anwenden, aber keinen Commit erzeugen. Perfekt, um mehrere Cherry-Picks zu einem Commit zu bündeln.

Bei BedarfMehrere Picks zu einem Commit zusammenfassen

Beispiel

git cherry-pick -n abc1234

Vor dem Commit den Editor öffnen, um die Nachricht zu ändern. Nutze das, um zu erklären, warum der Commit cherry-gepickt wurde.

Bei BedarfErgänzt die Nachricht des kopierten Commits um Kontext

Beispiel

git cherry-pick -e abc1234

Fortgeschritten (5)

Den Cherry-Pick nach dem Lösen der Konflikte fortsetzen. Gelöste Dateien musst du vorher mit 'git add' stagen.

EmpfohlenSetzt fort, nachdem du die Konflikte gelöst und gestagt hast

Beispiel

git cherry-pick --continue

Den Cherry-Pick abbrechen und den Branch auf den Stand davor zurücksetzen. Nutze das, wenn die Konflikte zu komplex sind oder du den falschen Commit gewählt hast.

EmpfohlenBricht sicher ab und stellt den Zustand vor dem Cherry-pick wieder her

Beispiel

git cherry-pick --abort

Den aktuellen Commit überspringen und mit den übrigen Commits der Folge weitermachen. Die Änderungen des übersprungenen Commits werden NICHT angewendet.

Bei BedarfÜberspringt einen Commit, dessen Änderungen du nicht mehr brauchst

Beispiel

git cherry-pick --skip

'(cherry picked from commit ...)' an die Commit-Nachricht anhängen. Hilft, die Herkunft cherry-gepickter Commits nachzuvollziehen.

EmpfohlenHält den Quell-Commit fest – unverzichtbar für Backports

Beispiel

git cherry-pick -x abc1234

Einen 'Signed-off-by'-Trailer mit deinem Namen und deiner E-Mail anhängen. Manche Projekte verlangen das aus rechtlichen oder Audit-Gründen.

Bei BedarfNur, wenn das Projekt Signed-off-by-Trailer verlangt

Beispiel

git cherry-pick -s abc1234

Erfahren (2)

Commits behalten, die schon von Anfang an leer waren (gleicher Tree wie ihr Elternteil). Commits, die leer werden, weil ihre Änderungen schon existieren, halten trotzdem an; nutze dafür --empty=keep.

Bei BedarfNur für Commits, die von Anfang an leer waren

Beispiel

git cherry-pick --allow-empty abc1234

Pflicht beim Cherry-Picken von Merge-Commits. Gibt an, welcher Elternteil (1 oder 2) die Hauptlinie ist. Meist -m 1, um die Änderungen des gemergten Branches zu bekommen.

Bei BedarfPflicht bei Merge-Commits; meist -m 1

Beispiel

git cherry-pick -m 1 abc1234

Experte (2)

Beim Anwenden der Änderungen die angegebene Merge-Strategie nutzen. Standard ist 'ort' (oder 'recursive' bei älterem Git). Es gibt keine Kurzform: -s bedeutet hier --signoff.

Nicht empfohlenDie Standardstrategie ort ist fast immer richtig

Beispiel

git cherry-pick --strategy=ort abc1234

Optionen an die Merge-Strategie übergeben. Üblich: 'theirs' (gepickte Änderungen bevorzugen), 'ours' (aktuellen Stand bevorzugen), 'patience' (bessere Diffs).

Nicht empfohlen-Xours / -Xtheirs verwerfen stillschweigend eine Seite kollidierender Hunks

Beispiel

git cherry-pick -Xtheirs abc1234

Die richtige Option wählen

git cherry-pick im Vergleich mit verwandten Befehlen

Verstehen, wann cherry-pick statt merge, rebase oder revert passt

BefehlAspektCherry-PickAnderer Befehl
ScopeNur bestimmte CommitsMerge: ganzer Branch / Rebase: ganzer Branch
Creates new commitsJa – neuer SHA, gleicher InhaltMerge: Merge-Commit / Rebase: schreibt alles um
Original staysJa – Original unberührtMerge: ja / Rebase: verwaist
Use caseBackports, gezieltes PortierenGanze Branches integrieren
History effectErzeugt doppelte ÄnderungenBewahrt oder linearisiert
ConflictsPro Commit während des PicksAm Merge-Punkt oder pro Rebase-Commit

Workflow-Beispiele

1
git checkout release-1.0

Auf den Release-Branch wechseln

2
git log main --oneline

Den Commit-Hash des Fixes finden

3
git cherry-pick -x abc123

Den Fix mit Herkunftsverweis anwenden

4
git push origin release-1.0

Den zurückportierten Fix pushen

1
git checkout main

Auf den Branch main wechseln

2
git log feature --oneline

Commits auf dem Feature-Branch prüfen

3
git cherry-pick abc123 def456

Nur die fertigen Commits picken

4
git push origin main

Die ausgewählten Commits pushen

1
git reflog

Den Commit-Hash im Reflog finden

2
git checkout main

Auf den Ziel-Branch wechseln

3
git cherry-pick abc123

Den verwaisten Commit anwenden

1
git checkout target-branch

Auf den Ziel-Branch wechseln

2
git cherry-pick A^..C

Commits A bis C (einschließlich) anwenden

3
git log --oneline

Prüfen, dass die Commits angewendet wurden

Fehlerbehebung

"commit is a merge but no -m option was given"

Ursache: Du versuchst, einen Merge-Commit zu cherry-picken, ohne den Elternteil anzugeben

Gib mit -m 1 oder -m 2 den Hauptlinien-Elternteil an

git cherry-pick -m 1 <merge-commit>

Konflikte beim Cherry-Pick

Ursache: Die Änderungen kollidieren mit deinem aktuellen Branch

Löse die Konflikte in den Dateien, führe git add aus, dann git cherry-pick --continue. Oder brich mit --abort ab

git add <resolved-files> && git cherry-pick --continue

"The previous cherry-pick is now empty"

Ursache: Die Änderungen des Commits sind schon in deinem Branch

Führe 'git commit --allow-empty' aus, um ihn trotzdem festzuhalten, oder 'git cherry-pick --skip', um ihn zu überspringen

git cherry-pick --skip

Cherry-pick hat doppelte Commits erzeugt

Ursache: Dieselben Änderungen existieren jetzt als verschiedene Commits auf verschiedenen Branches

Das ist erwartetes Verhalten. Nutze die Option -x, um die Beziehung zu dokumentieren

git cherry-pick -x <commit>

Der falsche Commit wurde cherry-gepickt

Ursache: Den falschen Commit-SHA gewählt

Wenn nicht gepusht: git reset --hard HEAD~1. Wenn gepusht: git revert auf den cherry-gepickten Commit

git reset --hard HEAD~1

Cherry-pick scheint nichts zu bewirken

Ursache: Der Commit ist vielleicht leer oder seine Änderungen sind schon angewendet

Sieh mit git diff HEAD~1 nach, was sich tatsächlich geändert hat

git diff HEAD~1

Tipps & Stolperfallen

Best Practices

  • ✓Nutze -x bei Backports, um den Verweis '(cherry picked from commit ...)' in die Commit-Nachricht zu schreiben
  • ✓Cherry-picke in chronologischer Reihenfolge – abhängige Commits müssen vom ältesten zum neuesten angewendet werden, um Konflikte zu vermeiden
  • ✓Nutze bei geteilten Branches lieber merge – cherry-pick erzeugt doppelte Commits, merge bewahrt die Historie
  • ✓Teste nach dem Cherry-Pick – der Commit kann im ursprünglichen Kontext funktionieren und im neuen scheitern
  • ✓Dokumentiere Cherry-Picks mit der Option -e in der Commit-Nachricht und erkläre, warum der Commit kopiert wurde
  • ✓Nutze --no-commit, um zusammengehörige Picks zu einem saubereren Commit zu bündeln
  • ✓Nutze lieber git cherry statt log, um noch nicht angewendete Commits zu finden
  • ✓Nimm bei Backports immer den Hash des Original-Commits in die Nachricht auf, damit er nachvollziehbar bleibt

Häufige Fehler

  • ✗-m bei Merge-Commits vergessen. Einen Merge-Commit ohne '-m 1' oder '-m 2' zu cherry-picken scheitert – du musst angeben, gegen welchen Elternteil verglichen wird.
  • ✗Gelöste Dateien vor --continue nicht stagen. Du musst 'git add' auf gelöste Dateien ausführen, bevor du 'git cherry-pick --continue' startest.
  • ✗Denselben Commit-Hash erwarten. Cherry-pick erzeugt NEUE Commits mit neuen SHAs – es kopiert Änderungen, es verschiebt keine Commits.
  • ✗Commits cherry-picken, die schon angewendet sind. Das führt zu Konflikten oder leeren Commits – prüfe vorher mit 'git log'.
  • ✗Commits in falscher Reihenfolge picken. Abhängige Commits müssen vom ältesten zum neuesten gepickt werden, sonst gibt es Konflikte.
  • ✗Cherry-pick auf öffentlichen Branches erzeugt doppelte Commits, wenn andere das Original haben – nutze bei geteilten Branches lieber merge.

FAQ

A:

Nein. Cherry-pick erzeugt einen NEUEN Commit mit denselben Änderungen, aber einem anderen SHA. Der Original-Commit bleibt, wo er war.

A:

Git-Commit-Hashes beruhen auf Inhalt, Elternteil, Autor, Datum und Nachricht. Cherry-pick behält Autor und Autorendatum, aber Elternteil und Committer-Datum unterscheiden sich, also ändert sich der Hash, auch wenn die Änderungen identisch sind.

A:

Ja! Zähle sie auf: git cherry-pick A B C, oder nutze Bereiche: git cherry-pick A^..C (schließt A und C ein).

A:

Nutze die Option -m: git cherry-pick -m 1 <merge-commit>. Die Zahl gibt an, welcher Elternteil die Hauptlinie ist (meist 1).

A:

A..B schließt A aus (Commits nach A bis B). A^..B schließt A ein (Commits von A bis einschließlich B).

A:

Wenn nicht gepusht: git reset --hard HEAD~1. Wenn gepusht: git revert <commit>, um einen Rückgängig-Commit zu erzeugen.

A:

Cherry-pick für bestimmte Commits. Rebase, um ganze Branches zu verschieben. Wenn du die meisten Commits eines Branches brauchst, ist rebase sauberer.