Cherry-pick — was es ist, Mechanismus und Anwendung in Git

Was ist Cherry-pick?

Cherry-pick ist ein Git-Befehl, der Änderungen aus einem bestimmten Commit kopiert und als neuen Commit im aktuellen Branch anwendet. Der Name leitet sich von der Metapher „Kirschen pflücken“ ab: Der Entwickler wählt nur die benötigten Commits aus und ignoriert den Rest.

Anders als Merge erstellt cherry-pick keinen Merge-Commit und erfordert keine vollständige Zusammenführung von Branches. Anders als Rebase überträgt cherry-pick keine Sequenz von Commits — nur die angegebenen. Dies macht cherry-pick zu einem idealen Werkzeug für die gezielte Übertragung von Korrekturen.

Laut Atlassian, 2025 wird cherry-pick von 47% der Teams verwendet, die gleichzeitig mit mehreren Release-Branches arbeiten. Cherry-pick ist besonders in der mobilen Entwicklung gefragt, wo mehrere Versionen einer Anwendung (LTS-Releases) gleichzeitig gewartet werden und Korrekturen zwischen ihnen übertragen werden müssen.

Übertragungsmechanismus

Bei der Ausführung von cherry-pick berechnet Git den Diff zwischen dem angegebenen Commit und seinem Parent, wendet diesen Diff dann auf den aktuellen Branch an. Wenn die Änderungen konfliktfrei übernommen werden — erstellt Git einen neuen Commit mit derselben Nachricht, aber einem neuen SHA. Bei einem Konflikt — pausiert cherry-pick zur manuellen Auflösung.

Wie funktioniert Cherry-pick

Die Syntax von cherry-pick ist einfach: Geben Sie den Hash des zu übertragenden Commits an. Git kopiert die Änderungen als neuen Commit in den aktuellen Branch. Die gleichzeitige Übertragung mehrerer Commits und ganzer Bereiche wird unterstützt.

# Einen einzelnen Commit in den aktuellen Branch übertragen
git cherry-pick a1b2c3d4

# Mehrere Commits übertragen
git cherry-pick a1b2c3d4 e5f6g7h8

# Einen Bereich von Commits übertragen (von a1b2 bis f9e8, ohne a1b2)
git cherry-pick a1b2c3d4..f9e8d7c6

Nach der Ausführung von cherry-pick erhält der aktuelle Branch einen neuen Commit mit den Änderungen aus der Quelle. Die Commit-Nachricht wird standardmäßig aus der Quelle kopiert, kann aber mit dem Flag -n (keinen Commit erstellen) oder --edit (Nachricht bearbeiten) geändert werden.

Beispiel für die Übertragung einer Korrektur

Betrachten wir ein typisches Szenario: Ein kritischer Fehler wird in develop gefunden und behoben, der auch im Release-Branch release/v2.0 vorhanden ist. Nur diese Korrektur soll übertragen werden, ohne den gesamten develop in den Release-Branch zu mergen.

# Den Commit-Hash mit der Korrektur in develop finden
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# Zum Release-Branch wechseln
git checkout release/v2.0

# Die Korrektur anwenden
git cherry-pick a1b2c3d4

# Bei Konflikt — auflösen und fortsetzen
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

Das -x-Flag fügt der Commit-Nachricht einen Verweis auf den ursprünglichen SHA hinzu: „(cherry picked from commit a1b2c3d4)“. Dies erleichtert die Nachverfolgung, woher der Commit übertragen wurde. Es wird empfohlen, -x in allen Szenarien außer temporären Entwürfen zu verwenden.

Arbeiten mit Konflikten

Bei einem Konflikt verhält sich cherry-pick wie merge: Git stoppt und markiert die Konfliktdateien. Der Entwickler löst den Konflikt, führt git add aus und dann git cherry-pick --continue. Zum Abbrechen — git cherry-pick --abort. Das Flag --strategy ermöglicht die Angabe einer Merge-Strategie (z. B. recursive mit Optionen).

# Auflösung eines Konflikts während cherry-pick
# Git zeigt Konfliktdateien an
git status

# Manuell auflösen, dann:
git add erlaubte_datei.kt
git cherry-pick --continue

# Oder cherry-pick abbrechen:
git cherry-pick --abort

Wann Cherry-pick verwenden

Cherry-pick ist optimal in Szenarien, in denen eine gezielte Übertragung von Änderungen ohne Zusammenführung ganzer Branches erforderlich ist. Betrachten wir fünf Hauptfälle, in denen cherry-pick die beste Wahl ist.

• Hotfix-Übertragung — eine Korrektur wird in develop gefunden, muss aber auf den Release-Branch (release/v2.0) angewendet werden. Cherry-pick überträgt nur den Fix-Commit, ohne unfertige Features aus develop zu beeinträchtigen
• Backport in ältere Versionen — eine Korrektur für die aktuelle Version muss in einen LTS-Release übertragen werden. Anstatt die gesamte aktuelle Codebasis zu mergen, wählt cherry-pick nur die benötigten Commits aus
• Rückgängigmachen eines Commits im falschen Branch — wenn ein Commit im falschen Branch erstellt wurde, überträgt cherry-pick ihn in den richtigen, und der ursprüngliche Commit wird rückgängig gemacht
• Dokumentationsübertragung — Änderungen an README oder Konfigurationsdateien, die in allen Branches vorhanden sein sollen, lassen sich bequem per cherry-pick übertragen
• Selektive Anwendung — aus einem Prototyp-Branch soll nur ein erfolgreicher Commit übernommen werden, ohne den gesamten Prototyp in die Hauptentwicklung zu übertragen

Für die mobile Entwicklung ist cherry-pick bei der Unterstützung mehrerer Versionen einer Anwendung von entscheidender Bedeutung. Wenn beispielsweise ein Fehler in Version 3.2 gefunden wird, die bereits bei Google Play veröffentlicht ist, und develop Code für Version 4.0 enthält — ermöglicht cherry-pick die Übertragung der Korrektur in den v3.x-Branch, ohne alle Breaking Changes zu mergen. Dies ist besonders relevant für Projekte, bei denen zwei oder mehr Hauptversionen mit unterschiedlichen APIs und Abhängigkeiten gleichzeitig gewartet werden.

Praktisches Beispiel: In einer mobilen App wird ein Absturz bei der Authentifizierung über Google Sign-In auf Android 12 festgestellt. Die Korrektur wird in develop vorgenommen und durchläuft das Code-Review. Der aktuelle Release-Branch v2.5 befindet sich jedoch bereits in der Beta-Testphase. Cherry-pick des Fix-Commits von develop nach release/v2.5 ermöglicht es, die Korrektur in den nächsten Release aufzunehmen, ohne andere Änderungen zu übertragen, die noch nicht zur Veröffentlichung bereit sind.

Bei der Verwendung von cherry-pick in mobilen Projekten ist es wichtig, Abhängigkeiten zu berücksichtigen: Wenn die Korrektur Dateien betrifft, die in develop nach dem Abweichungspunkt des Release-Branches geändert wurden, kann cherry-pick einen unvollständigen Satz von Änderungen mit sich bringen. In solchen Fällen muss überprüft werden, ob alle zugehörigen Änderungen ebenfalls übertragen wurden, da die App andernfalls möglicherweise nicht kompiliert wird oder nicht korrekt funktioniert. Überprüfen Sie nach cherry-pick immer den Build, bevor Sie Änderungen in den gemeinsamen Branch pushen.

Cherry-pick vs Merge vs Rebase

Die drei wichtigsten Werkzeuge zur Integration von Änderungen in Git — merge, rebase und cherry-pick — lösen unterschiedliche Aufgaben. Die Wahl hängt davon ab, wie viel Änderung übertragen werden muss und wie der Verlauf aussehen soll.

Merge — wenn Sie zwei Branches vollständig zusammenführen und Verzweigungsinformationen beibehalten möchten. Rebase — wenn Sie einen persönlichen Branch mit sauberem Verlauf auf den neuesten Stand bringen möchten. Cherry-pick — wenn Sie nur einen Commit oder mehrere ausgewählte Commits benötigen.

In der Praxis werden diese Werkzeuge kombiniert: Eine Funktion wird mit regelmäßigem Rebase auf develop entwickelt, dann über --no-ff merge zusammengeführt, und wenn eine Korrektur in einen anderen Branch übertragen werden muss, wird cherry-pick verwendet. Jedes Werkzeug löst seine eigene Aufgabe in seiner eigenen Phase.

Risiken und Einschränkungen von Cherry-pick

Cherry-pick ist ein nützliches, aber potenziell gefährliches Werkzeug, wenn es falsch oder übermäßig verwendet wird. Die Hauptrisiken stehen im Zusammenhang mit Commit-Duplizierung, Kontextverlust und Konflikten bei späteren Merges.

• Commit-Duplizierung — wenn derselbe Commit später über merge in den Branch gelangt, erstellt Git einen zweiten, in den Änderungen identischen Commit. Dies verschmutzt den Verlauf und erschwert git bisect
• Kontextverlust — cherry-pick überträgt den Diff, aber keine Informationen über Parent-Commits und Abhängigkeiten. Wenn cherry-pick Commit A ohne Commit B angewendet hat, von dem A abhing, können logische Fehler auftreten
• Merge-Konflikte — nach cherry-pick kann Git bei einer vollständigen Branch-Zusammenführung dieselben Änderungen zweimal sehen und Konflikte erzeugen, die bei einem normalen Merge vermieden worden wären
• Fehlende Rückverfolgbarkeit — ohne das -x-Flag ist es unmöglich zu wissen, dass ein Commit aus einem anderen Branch übertragen wurde. Bei der Suche nach dem Ursprung einer Änderung kann ein Entwickler Stunden damit verbringen, die Herkunft des Commits herauszufinden

Empfehlungen zur Risikominimierung: Verwenden Sie immer das -x-Flag, um den ursprünglichen SHA anzugeben, dokumentieren Sie den Grund für cherry-pick in der Commit-Nachricht, und verwenden Sie wenn möglich merge anstelle von cherry-pick, wenn der Kontext dies zulässt. Wenn cherry-picks zahlreich werden — ziehen Sie eine Umstrukturierung der Branches in Betracht.

Automatisierte Prüfungen für Cherry-pick

CI-Pipelines sollten cherry-pick als separates Szenario betrachten. Es wird empfohlen, eine automatische Prüfung einzurichten: Wenn ein cherry-pick-Commit erstellt wird, überprüft CI, ob die geänderten Dateien dem erwarteten Satz entsprechen, und führt Tests für die betroffenen Module durch. Dies reduziert das Risiko von Regressionen bei der Übertragung von Änderungen zwischen Branches.