Cherry-Pick gezielt einsetzen statt ganze Branches zu mergen

1. Was Cherry-Pick mechanisch macht

git cherry-pick überträgt den Diff genau eines Commits auf den aktuell ausgecheckten Branch und erzeugt dort einen neuen Commit mit eigener SHA. Der Ursprungscommit bleibt unverändert an seiner Stelle im Quell-Branch stehen, Autor und Commit-Message werden übernommen, aber Parent-Commit, Zeitstempel des Commits und die SHA sind neu. Technisch ist das Vorgehen vergleichbar mit git diff commit^..commit gefolgt von git apply und einem anschließenden Commit, nur dass Git dabei automatisch versucht, den Patch anhand des Drei-Wege-Merge-Algorithmus einzupassen, statt ihn stur zeilenweise anzuwenden.

Der entscheidende Punkt: Cherry-Pick arbeitet auf Ebene einzelner Änderungen, nicht auf Ebene des Commit-Graphen. Während merge und rebase die Beziehung zwischen zwei vollständigen Branch-Historien herstellen, betrachtet cherry-pick einen isolierten Commit als eigenständige, portable Einheit. Das macht das Kommando ideal für gezielte Eingriffe wie Hotfixes, aber ungeeignet, um dauerhaft zwei Branches synchron zu halten, weil dabei keine gemeinsame Merge-Basis entsteht, auf die spätere Git-Operationen zurückgreifen könnten.

2. Der klassische Hotfix-Anwendungsfall

Der Standardfall für cherry-pick: Ein kritischer Bug wird in der Produktion auf einem Release-Branch wie release/2.4 entdeckt und dort unter Zeitdruck direkt gefixt und deployed. Damit dieser Fix nicht bei der nächsten Feature-Entwicklung verloren geht oder in einem zukünftigen Release erneut auftaucht, muss er auch in main beziehungsweise develop landen. Statt den kompletten Release-Branch mit all seinen Backport-spezifischen Anpassungen in main zu mergen, wird gezielt nur der eine Fix-Commit per cherry-pick übertragen.

In Projekten mit mehreren parallel gepflegten Release-Branches, etwa für unterschiedliche LTS-Versionen, wird derselbe Fix-Commit häufig auf mehrere Ziel-Branches gleichzeitig portiert. Der Fix wandert dann von release/2.4 aus per cherry-pick nach main, nach release/2.5 und gegebenenfalls auf einen unterstützten release/2.3-Branch, jeweils als eigenständiger Commit mit eigener SHA. Diese Vorgehensweise hält jeden Branch minimal und nachvollziehbar verändert, statt größere Merge-Operationen mit potenziell unerwarteten Nebenwirkungen auszulösen.

#!/usr/bin/env bash
# Hotfix von release/2.4 nach main portieren

git checkout release/2.4
git log --oneline -5
# a1b2c3d fix(checkout): prevent double order submission

git checkout main
git cherry-pick a1b2c3d
# Applies the diff of a1b2c3d as a new commit on main

git log --oneline -1
# f9e8d7c fix(checkout): prevent double order submission

3. Cherry-Pick vs. Merge und Rebase im Vergleich des Funktionsumfangs

merge integriert die vollständige Historie eines Branches, indem es einen Merge-Commit mit zwei Parents erzeugt, der beide Entwicklungslinien wieder zusammenführt. rebase spielt eine ganze Sequenz von Commits auf einer neuen Basis erneut ab und schreibt dabei jeden dieser Commits mit neuer SHA um. Beide Operationen beziehen sich also immer auf einen zusammenhängenden Bereich der Historie, nicht auf einen einzelnen, herausgelösten Commit.

cherry-pick dagegen ignoriert bewusst alles, was im Quell-Branch vor und nach dem gewählten Commit passiert ist. Wer versucht, mit mehreren einzelnen cherry-picks nach und nach einen ganzen Feature-Branch nachzubilden, bekommt am Ende zwar ähnlichen Code, aber eine völlig andere Commit-Struktur ohne die ursprünglichen Merge-Beziehungen. Für das gezielte Portieren einzelner Änderungen ist das genau richtig, für die vollständige Integration eines Branches ist es der falsche Werkzeugtyp.

4. Konflikte beim Cherry-Picking behandeln

Ein Konflikt entsteht während cherry-pick, wenn der Kontext um die geänderten Zeilen auf dem Zielbranch bereits abweicht, etwa weil dort seither andere Änderungen an derselben Stelle vorgenommen wurden. Git markiert die betroffenen Dateien mit den bekannten Konfliktmarkern und pausiert den Vorgang, ohne automatisch einen Commit zu erzeugen. Der Cherry-Pick-Zustand bleibt dabei aktiv, erkennbar an der Datei .git/CHERRY_PICK_HEAD, bis der Konflikt explizit aufgelöst wird.

Nach dem manuellen Beheben der Konfliktmarker werden die betroffenen Dateien mit git add markiert und der Vorgang mit git cherry-pick --continue abgeschlossen. Wer den gesamten Cherry-Pick verwerfen und zum Zustand vor dem Kommando zurückkehren möchte, nutzt git cherry-pick --abort. Bei einer Reihe von Commits kann ein einzelner, bereits überflüssiger oder nicht anwendbarer Commit mit git cherry-pick --skip übersprungen werden, ohne den restlichen Vorgang abzubrechen.

#!/usr/bin/env bash
# Conflict during cherry-pick: manual resolution workflow

git cherry-pick d4e5f6a
# error: could not apply d4e5f6a... fix(cart): recalc totals
# CONFLICT (content): Merge conflict in app/code/.../Cart.php

git status
# Unmerged paths: app/code/Mironsoft/Cart/Model/Cart.php

# Resolve conflict markers manually in the editor, then:
git add app/code/Mironsoft/Cart/Model/Cart.php
git cherry-pick --continue

# Or discard the whole cherry-pick and return to the prior state:
git cherry-pick --abort

# Or skip a single unneeded commit in a multi-commit pick:
git cherry-pick --skip

5. Commit-Bereiche cherry-picken

Statt einzelner SHAs akzeptiert cherry-pick auch Commit-Bereiche in der Form git cherry-pick A..B. Dabei wird, wie bei rebase-Bereichen üblich, Commit A selbst ausgeschlossen und nur die Commits ab dem direkten Nachfolger von A bis einschließlich B angewendet. Das eignet sich, wenn mehrere zusammenhängende Commits eines Fixes gemeinsam portiert werden müssen, etwa ein Bugfix plus dazugehöriger Test-Commit.

Mit der Option --no-commit beziehungsweise -n lassen sich mehrere Commits aus einem Bereich zunächst nur ins Arbeitsverzeichnis und den Index übernehmen, ohne dass Git automatisch für jeden einzelnen einen eigenen Commit erzeugt. So kann man die kombinierten Änderungen vor dem eigentlichen Commit noch einmal prüfen, anpassen oder zu einem einzigen aussagekräftigen Commit zusammenfassen, statt die ursprüngliche Commit-Granularität aus dem Quell-Branch zu übernehmen.

#!/usr/bin/env bash
# Cherry-pick a contiguous range of commits (A excluded, B included)

git log --oneline release/2.4
# 9f1a2b3 test(cart): cover recalculation edge case
# d4e5f6a fix(cart): recalc totals after coupon removal
# 7c8d9e0 chore(cart): unrelated cleanup commit

git checkout main
git cherry-pick 7c8d9e0..9f1a2b3
# Applies d4e5f6a and 9f1a2b3, excludes 7c8d9e0

# Stage multiple commits without individual commits, then squash:
git cherry-pick -n 7c8d9e0..9f1a2b3
git commit -m "fix(cart): recalc totals after coupon removal (backport)"

6. Die -x Flag für Nachvollziehbarkeit

Die Option -x fügt der Commit-Message des neu erzeugten Commits automatisch die Zeile (cherry picked from commit sha) hinzu. Dadurch bleibt für jeden, der später git log auf dem Zielbranch liest, sofort erkennbar, dass dieser Commit kein originärer Commit ist, sondern von einem anderen Commit stammt, inklusive dessen vollständiger SHA. Ohne -x sieht ein cherry-gepickter Commit äußerlich identisch aus wie ein regulärer, eigenständiger Commit.

Für Release-Management und Audit-Trails ist dieser Unterschied relevant: Wenn ein Sicherheitsfix auf drei Branches portiert wurde, lässt sich mit -x im Nachhinein lückenlos nachvollziehen, welcher Commit auf welchem Branch die Quelle war, ohne Commit-Messages oder externe Dokumentation durchsuchen zu müssen. Viele Projekte mit striktem Release-Prozess erzwingen -x über einen Pre-Commit-Hook oder eine CI-Prüfung, gerade weil die Information sonst nur im Gedächtnis der beteiligten Entwickler existiert.

#!/usr/bin/env bash
# Cherry-pick with -x for a traceable backport

git checkout main
git cherry-pick -x a1b2c3d

git log -1
# commit f9e8d7c...
# Author: Jane Doe <jane@mironsoft.de>
#
#     fix(checkout): prevent double order submission
#
#     (cherry picked from commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0)

7. Das Risiko divergenter Historie

Wird cherry-pick als Ersatz für regelmäßige Merges genutzt, etwa um einen Release-Branch dauerhaft mit main synchron zu halten, entstehen für dieselbe logische Änderung mehrere Commits mit unterschiedlichen SHAs auf unterschiedlichen Branches. Git kennt keinen automatischen Zusammenhang zwischen diesen Commits, wodurch spätere Merge-Versuche zwischen den betroffenen Branches denselben Inhalt erneut als Konflikt oder als scheinbar neue Änderung präsentieren, obwohl der Code inhaltlich bereits identisch ist.

Mit jedem weiteren cherry-gepickten Commit wächst diese Divergenz, und die Commit-Historie verliert ihren Aussagewert als verlässliches Abbild der tatsächlichen Code-Beziehungen. Teams, die cherry-pick systematisch statt punktuell einsetzen, berichten regelmäßig von Debugging-Sessions, in denen unklar ist, ob ein Fix auf einem bestimmten Branch bereits vorhanden ist oder nicht, weil git log allein die Frage nicht zuverlässig beantwortet. Cherry-pick sollte deshalb die Ausnahme für gezielte Portierungen bleiben, nicht die Standardmethode für Branch-Synchronisation.

8. Patch-IDs und die Erkennung bereits gepickter Commits

Damit Git trotz unterschiedlicher SHAs erkennen kann, dass zwei Commits inhaltlich dieselbe Änderung enthalten, berechnet es eine sogenannte Patch-ID. Der Befehl git patch-id erzeugt dafür einen Hash über den reinen Diff-Inhalt eines Commits, unabhängig von Zeilennummern im Kontext, Commit-Message, Autor oder Zeitstempel. Zwei Commits mit identischem Diff-Inhalt erhalten dieselbe Patch-ID, selbst wenn ihre SHAs komplett verschieden sind.

Auf dieser Grundlage zeigt git log --cherry-pick beim Vergleich zweier Branches nur die Commits an, die tatsächlich noch nicht auf beiden Seiten vorhanden sind, und git cherry listet explizit an, welche Commits eines Branches bereits als äquivalenter Patch im anderen Branch existieren. Die Krux dabei: Jede nachträgliche Änderung am Patch, etwa durch eine Konfliktauflösung mit leicht abweichendem Ergebnis, verändert die Patch-ID und macht den Zusammenhang für Git wieder unsichtbar, was in der Praxis zu verwirrenden False Negatives bei der automatischen Duplikaterkennung führt.

#!/usr/bin/env bash
# Detect already cherry-picked commits via patch-id

# Compare two branches: show commits on release/2.4 with no
# equivalent patch on main
git log --cherry-pick --right-only --oneline main...release/2.4

# Explicit patch-id comparison for a single commit
git show a1b2c3d | git patch-id
# a9f8e7d6c5b4... a1b2c3d4e5f6...

git show f9e8d7c | git patch-id
# a9f8e7d6c5b4... f9e8d7c1a2b3...
# Same patch-id prefix confirms identical underlying change

# git cherry marks already-applied commits with a minus sign
git cherry main release/2.4
# - a1b2c3d already applied to main (same patch-id)
# + b2c3d4e not yet applied to main

9. Best Practices: Cherry-Pick, Merge oder Rebase im direkten Vergleich

Die Wahl zwischen cherry-pick, merge und rebase hängt fast immer vom Umfang der zu übertragenden Änderung und vom Ziel der Operation ab, nicht von persönlicher Präferenz. Die folgende Übersicht ordnet die drei Werkzeuge typischen Szenarien aus dem Entwickleralltag zu.

Als Faustregel gilt: Je kleiner und isolierter die zu übertragende Änderung, desto eher ist cherry-pick das richtige Werkzeug. Sobald mehrere zusammenhängende Commits oder eine vollständige Entwicklungslinie übertragen werden sollen, liefern merge und rebase die saubereren, besser nachvollziehbaren Ergebnisse, weil sie die tatsächliche Beziehung zwischen den Branches im Commit-Graphen abbilden statt sie zu verschleiern.

10. Zusammenfassung

Cherry-Pick gezielt einsetzen bedeutet, das Kommando für genau die Situation zu reservieren, für die es gebaut wurde: das punktuelle Portieren einzelner, klar abgegrenzter Commits wie Hotfixes zwischen Branches. Der mechanische Kern, ein Commit wird als Diff extrahiert und mit neuer SHA auf einen anderen Branch angewendet, macht das Werkzeug leichtgewichtig und schnell, aber auch blind für den größeren Kontext der Quell-Historie. Die Flag -x sorgt dafür, dass diese Herkunft nachvollziehbar bleibt, und git patch-id ermöglicht es Git, inhaltlich identische Commits über SHA-Grenzen hinweg zu erkennen.

Wer cherry-pick regelmäßig für mehr als isolierte Ausnahmefälle einsetzt, erkauft sich kurzfristige Bequemlichkeit mit langfristig divergierender, schwer lesbarer Historie. Die bewusste Entscheidung zwischen cherry-pick, merge und rebase anhand von Umfang und Zielsetzung der Änderung bleibt der zuverlässigste Weg, um Branches synchron und die Commit-Historie als verlässliche Dokumentation zu erhalten.

11. FAQ: Cherry-Pick gezielt einsetzen