git cherry-pick: einzelne Commits in einen anderen Branch übernehmen

git cherry-pick überträgt die Änderungen eines einzelnen Commits in den aktuellen Branch, ohne den ganzen Branch zu mergen. Git berechnet den Diff des gewählten Commits gegenüber seinem Elternteil, wendet ihn auf Ihren HEAD an und erstellt einen neuen Commit — mit derselben Nachricht und demselben Autor, aber einem anderen Hash, weil er einen anderen Elternteil hat.

Typisches Szenario: Im Feature-Branch haben Sie einen Bug behoben, und der Fix wird dringend im Release-Branch gebraucht, in dem das Feature noch nicht fertig ist. Den ganzen Branch zu mergen geht nicht, einen einzelnen Commit zu übernehmen schon.

Einen Commit in einen anderen Branch übernehmen

Suchen Sie zuerst den Hash des Commits, wechseln Sie dann in den Branch, in den er soll, und führen Sie cherry-pick aus.

# 1. Commit im Branch feature finden
git log --oneline feature
a1b2c3d Division durch null bei der Rabattberechnung beheben
9f8e7d6 Neue Zahlungsseite hinzufügen

# 2. In den Ziel-Branch wechseln
git switch release-1.4

# 3. Commit übernehmen
git cherry-pick a1b2c3d
[release-1.4 4e5f6a7] Division durch null bei der Rabattberechnung beheben
 Date: Mon Oct 5 14:12:03 2026 +0300
 1 file changed, 3 insertions(+), 1 deletion(-)

Beachten Sie: Der neue Commit hat den Hash 4e5f6a7, nicht a1b2c3d. Das sind zwei verschiedene Objekte mit denselben Änderungen. Der Quell-Branch feature bleibt unverändert.

Statt eines Hashs können Sie jede Commit-Referenz angeben: git cherry-pick feature nimmt den letzten Commit des Branches feature, git cherry-pick feature~2 den drittletzten.

Mehrere Commits übernehmen

Als Liste

Hashes lassen sich als Liste übergeben — Git wendet sie in der angegebenen Reihenfolge an und erstellt ebenso viele neue Commits.

git cherry-pick a1b2c3d 7c8d9e0 3f4a5b6

Die Reihenfolge zählt: Hängt der zweite Commit vom ersten ab und Sie listen sie umgekehrt auf, bekommen Sie einen Konflikt oder kaputten Code. Sicherer ist es, von alt nach neu anzugeben.

Als Bereich

Für aufeinanderfolgende Commits gibt es die Bereichssyntax. Hier lauert eine Falle, in die fast jeder tappt: A..B bedeutet „Commits, die von B aus erreichbar sind, aber nicht von A“ — A selbst gehört also nicht zum Bereich.

# Übernimmt die Commits NACH A bis einschließlich B
git cherry-pick A..B

# Übernimmt A und alles bis einschließlich B
git cherry-pick A^..B

Wollen Sie alles übernehmen, was in feature ist und in main fehlt, ist git cherry-pick main..feature praktisch. Bei vielen Commits sollten Sie aber überlegen, ob Sie nicht eher rebase oder merge brauchen.

Nützliche Flags von git cherry-pick

Wozu -x?

In einem halben Jahr sieht jemand den Fix im Release-Branch und will wissen, woher er stammt. Die von -x hinzugefügte Zeile beantwortet das direkt:

git cherry-pick -x a1b2c3d
git log -1
    Division durch null bei der Rabattberechnung beheben

    (cherry picked from commit a1b2c3d4e5f60718293a4b5c6d7e8f9012345678)

Verwenden Sie -x, wenn der Quell-Commit bereits veröffentlicht ist. Stammt er aus Ihrem lokalen Branch, den Sie später löschen, führt der Verweis ins Leere — dort ist das Flag überflüssig.

Mehrere Commits zu einem zusammenfassen: -n

git cherry-pick -n a1b2c3d 7c8d9e0
git status          # Änderungen beider Commits im Index
git commit -m "Korrekturen an der Rabattberechnung"

Konflikte bei cherry-pick lösen

Ein Konflikt entsteht, wenn die Änderungen des Commits nicht auf den aktuellen Code passen: Im Ziel-Branch sehen dieselben Zeilen bereits anders aus. Git hält an und meldet das.

git cherry-pick a1b2c3d
Auto-merging src/discount.js
CONFLICT (content): Merge conflict in src/discount.js
error: could not apply a1b2c3d... Division durch null bei der Rabattberechnung beheben
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".

Dann haben Sie drei Möglichkeiten:

1. Lösen und fortsetzen. Öffnen Sie die Datei, entfernen Sie die Marker <<<<<<<, =======, >>>>>>> und lassen Sie die richtige Variante stehen, dann git add src/discount.js und git cherry-pick --continue.
2. Commit überspringen. Beim Übernehmen einer Liste überspringt git cherry-pick --skip den problematischen Commit und macht mit dem nächsten weiter.
3. Alles abbrechen. git cherry-pick --abort setzt den Branch auf den Stand vor Beginn der Operation zurück.

Außerdem gibt es git cherry-pick --quit: Es beendet die Operation, behält aber die bereits angewendeten Commits und den aktuellen Zustand der Dateien. Nützlich, wenn die Hälfte der Liste erfolgreich übernommen wurde und Sie manuell weitermachen wollen.

Wiederholen sich Konflikte ständig (etwa wenn Sie regelmäßig Fixes in mehrere Release-Branches übertragen), aktivieren Sie git config rerere.enabled true — Git merkt sich, wie Sie den Konflikt gelöst haben, und wendet die Lösung beim nächsten Mal automatisch an.

Einen Merge-Commit übernehmen

Ein Merge-Commit hat zwei Eltern, und Git weiß nicht, gegenüber welchem der Diff berechnet werden soll. Ohne Hinweis erhalten Sie einen Fehler:

git cherry-pick 5d6e7f8
error: commit 5d6e7f8 is a merge but no -m option was given.

Das Flag -m 1 besagt: Berechne die Änderungen gegenüber dem ersten Elternteil — meist der Branch, in den gemergt wurde. So übernehmen Sie alles, was der gemergte Branch mitgebracht hat, in einem Commit.

git cherry-pick -m 1 5d6e7f8

Bedenken Sie, dass Git den Branch danach nicht als gemergt betrachtet: Bei einem späteren Merge kann es versuchen, dieselben Änderungen erneut anzuwenden.

git cherry-pick vs. git apply: der Unterschied

git apply wird oft in einem Atemzug mit cherry-pick genannt, weil beide Befehle „Änderungen aufbringen“. Sie arbeiten aber mit unterschiedlichen Eingaben.

Beispiel für git apply, wenn der Commit nicht in Ihrem Repository ist — ein Kollege hat den Diff als Datei geschickt:

# Der Kollege erstellt
git diff main..fix-discount > fix.patch

# Sie prüfen und wenden an
git apply --check fix.patch   # prüfen, ob der Patch passt
git apply fix.patch           # auf das Arbeitsverzeichnis anwenden
git apply --3way fix.patch    # bei Abweichungen mit Konfliktmarkern

Soll ein Commit vollständig mit Autor und Nachricht weitergegeben werden, nutzen Sie das Paar git format-patch und git am: Ersteres speichert Commits in Dateien, Letzteres erzeugt daraus Commits. Im Grunde ist das cherry-pick „per E-Mail“.

Übrigens ist cherry-pick auch aus einem anderen Repository möglich: Fügen Sie es als Remote hinzu, führen Sie git fetch aus, und die Commits sind per Hash verfügbar.

Wann cherry-pick eine schlechte Idee ist

Cherry-pick erzeugt Duplikate: Dieselbe Änderung lebt in der Historie unter zwei Hashes. In kleinen Dosen ist das in Ordnung, aber in manchen Szenarien schadet es.

• Dutzende Commits übernehmen. Wenn Sie fast den ganzen Branch übertragen, ist das ein Fall für rebase oder merge. Cherry-pick erzeugt hier eine lange Historie aus Duplikaten und mehr Konflikte.
• Übernahmen in beide Richtungen. Ein Commit wurde von feature nach main übernommen, später wird feature in main gemergt. Git kommt meist damit klar (die Änderungen sind identisch), aber wurden die Zeilen nach der Übernahme bearbeitet, gibt es einen Konflikt aus heiterem Himmel.
• Abhängige Commits. Ein Commit nutzt eine Funktion, die zwei Commits vorher hinzugefügt wurde. Cherry-pick übernimmt nur diesen Commit, und der Code im Ziel-Branch lässt sich nicht bauen. Prüfen Sie nach der Übernahme immer Build und Tests.

Bewährte Praxis für Hotfixes: den Fix direkt im ältesten unterstützten Branch machen und ihn „nach oben“ in neuere mergen. Dann ist cherry-pick nur noch die Ausnahme.

cherry-pick rückgängig machen

Läuft die Operation noch (Konflikt) — git cherry-pick --abort. Ist der Commit schon erstellt, aber nicht gepusht, entfernen Sie ihn:

git reset --hard HEAD~1

Wurde der Commit bereits in einen gemeinsamen Branch gepusht, dürfen Sie die Historie nicht umschreiben — erstellen Sie einen Gegen-Commit:

git revert 4e5f6a7

Und falls Sie reset ausgeführt und es sich anders überlegt haben, finden Sie den verlorenen Commit über git reflog.

Prüfen, ob ein Commit schon übernommen wurde

Da die Hashes verschieden sind, hilft ein normales git branch --contains nicht. Git kann Commits aber anhand des Inhalts ihrer Änderungen vergleichen (patch-id):

git cherry -v release-1.4 feature
- a1b2c3d Division durch null bei der Rabattberechnung beheben
+ 9f8e7d6 Neue Zahlungsseite hinzufügen

Ein Minus bedeutet, dass eine gleichwertige Änderung in release-1.4 bereits existiert, ein Plus, dass sie noch fehlt. Alternativ blendet git log --cherry-pick --oneline release-1.4...feature die „Zwillings-Commits“ aus. Haben Sie -x verwendet, können Sie einfach nach der Nachricht suchen: git log --grep="cherry picked from commit a1b2c3d".

Fazit

git cherry-pick ist ein Präzisionswerkzeug: einen Hotfix ins Release übernehmen, einen nützlichen Commit aus einem verwaisten Branch retten, einen versehentlich im falschen Branch gemachten Commit an die richtige Stelle bringen. Merken Sie sich drei Dinge: Der neue Commit bekommt einen neuen Hash, der Bereich A..B schließt A nicht ein, und für öffentliche Branches lohnt sich -x. Wenn Sie keinen Commit, sondern einen Diff aus einer Datei übertragen wollen, nehmen Sie git apply. Rebase, stash, cherry-pick und Tags werden im Git-Kurs ausführlich in der Praxis behandelt.