Cherry-pick: Was es ist, wie man es ausführt und Git-Befehle

Was ist cherry-pick in Git

Cherry-pick ist der git cherry-pick Befehl, der Änderungen aus einem vorhandenen Commit nimmt und sie als neuen Commit im aktuellen Branch anwendet. Der ursprüngliche Commit bleibt in seinem eigenen Branch erhalten, während eine Kopie der Änderungen im Ziel-Branch erstellt wird. Der Befehl ist nützlich, wenn Sie eine bestimmte Korrektur übertragen müssen, ohne einen gesamten Branch zu verschieben.

Syntax: git cherry-pick <commit-hash>. Git analysiert den Unterschied (diff) des angegebenen Commits zu seinem Eltern-Commit und wendet diesen Unterschied auf den aktuellen Branch an. Wenn mehrere Dateien geändert wurden, werden sie alle zusammen übertragen. Der Befehl akzeptiert auch Bereiche: git cherry-pick A..B — alle Commits von A bis B, außer A.

Flags erweitern die Möglichkeiten: -n (--no-commit) wendet Änderungen auf das Arbeitsverzeichnis und den Index an, ohne einen Commit zu erstellen — nützlich, wenn Sie Änderungen mehrerer Commits in einem zusammenfassen möchten. Das Flag -x fügt der Commit-Nachricht eine Zeile (cherry picked from commit ...) hinzu, was die Nachverfolgung der Herkunft von Änderungen im Verlauf erleichtert.

# Cherry-pick eines einzelnen Commits per Hash
git cherry-pick a1b2c3d

# Cherry-pick mehrerer Commits (nacheinander)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick ohne Auto-Commit
git cherry-pick -n a1b2c3d

# Flag -x fügt Verweis auf ursprünglichen Commit hinzu
git cherry-pick -x a1b2c3d

Wann verwendet man cherry-pick

Das Hauptszenario ist die Übertragung von Korrekturen zwischen Release-Branches. Stellen Sie sich vor: In develop wurde ein kritischer Fehler gefunden und behoben. Der Release-Branch release/v2.1 ist bereits abgetrennt und enthält ebenfalls diesen Fehler. Ein Merge des gesamten develop in release würde viele unfertige Codeänderungen mitbringen, während cherry-pick des einzelnen Fix-Commits eine sichere und präzise Lösung darstellt.

Das zweite Szenario ist das Rückgängigmachen von Änderungen mit späterer Wiederherstellung. Wenn ein Commit per git revert rückgängig gemacht wurde und sich später herausstellt, dass der Revert ein Fehler war — stellt cherry-pick des rückgängig gemachten Commits die Änderungen wieder her. Dies ist korrekter als das Rückgängigmachen eines Reverts, da keine wiederholten Konflikte entstehen.

Das dritte Szenario ist das Zusammenführen von Commits aus verschiedenen Feature-Branches in einen Test-Branch für Integrationstests. Anstatt mehrere unfertige Branches (mit unvollständigem Code) zu mergen, können Sie nur die fertigen Commits aus jedem auswählen und deren Zusammenarbeit testen.

• Bugfixes — Übertragen einer Korrektur von develop nach release ohne unfertigen Code.
• Hotfix — Anwenden einer Korrektur aus einem hotfix-Branch auf main und develop gleichzeitig.
• Rückgängigmachen eines fehlerhaften Reverts — Cherry-pick des rückgängig gemachten Commits zur Wiederherstellung der Änderungen.
• Tests — Sammeln ausgewählter Commits aus verschiedenen Branches für Integrationstests.

Cherry-pick vs rebase und merge

Cherry-pick unterscheidet sich von rebase und merge dadurch, dass es auf der Ebene einzelner Commits und nicht ganzer Branches arbeitet. Während rebase alle Commits eines Branches überträgt und merge zwei Branches zusammenführt, wählt cherry-pick nur die benötigten aus. Dies macht es zu einem präziseren Werkzeug, aber auch zu einem manuelleren.

Ein weiterer Unterschied ist die Autorenschaft. Beim cherry-pick behält Git standardmäßig den Autor des ursprünglichen Commits bei, aber der Committer wird der aktuelle Benutzer. Die Commit-Nachricht kann die Herkunft über das -x Flag nachverfolgen. Beim rebase werden sowohl Autor als auch Committer zum aktuellen Benutzer mit einem neuen Hash.

Leistung: Cherry-pick eines einzelnen Commits ist schneller als das Zusammenführen zweier Branches mit vielen Commits. Wenn Sie jedoch Dutzende von Commits übertragen müssen, ist es besser, einen temporären Branch zu erstellen und einen rebase durchzuführen — das ist effizienter und erfordert nicht die Angabe Dutzender Hashes.

Mehrere Commits übertragen

Mehrere Commits können mit einem einzigen Befehl übertragen werden, indem ihre Hashes durch Leerzeichen getrennt aufgelistet werden: git cherry-pick A B C. Git wendet die Commits nacheinander in der angegebenen Reihenfolge an. Wenn ein Commit einen Konflikt verursacht, pausiert cherry-pick, und der Entwickler muss den Konflikt lösen und dann mit git cherry-pick --continue fortfahren.

Commit-Bereich: git cherry-pick A..B (alle Commits nach A bis B, außer A) und git cherry-pick A^..B (alle Commits von A einschließlich bis B). Bereiche sind praktisch, wenn Sie alle Commits aus einem Branch ohne die Elternbeziehung übertragen müssen — zum Beispiel beim Verschieben einer fertigen Funktion von einem alten Branch in einen neuen.

Das Flag --strategy bestimmt, wie Git Änderungen anwendet. Standardmäßig wird die recursive-Strategie verwendet, aber Sie können ours oder theirs angeben, um automatisch eine Konfliktseite auszuwählen. Das Flag --mainline wird beim cherry-pick eines Merge-Commits verwendet — es gibt die Elternnummer (1 oder 2) an, gegen die der Diff berechnet wird.

# Cherry-pick Commit-Bereich
git cherry-pick develop~5..develop~2

# Cherry-pick von Merge-Commit (Elternteil angeben)
git cherry-pick -m 1 m9n0o1p

# Theirs-Strategie verwenden
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Nach Konfliktlösung fortsetzen
git cherry-pick --continue

Konflikte bei cherry-pick

Konflikte bei cherry-pick treten auf, wenn Änderungen des übertragenen Commits dieselben Zeilen betreffen, die im Ziel-Branch geändert wurden. Git pausiert die Ausführung, markiert die konfliktbehafteten Dateien und wartet auf die Auflösung. Im Status werden solche Dateien als both modified angezeigt.

Schritte zur Konfliktlösung: Öffnen Sie die konfliktbehaftete Datei, suchen Sie die Konfliktmarkierungen (<<<<<<<, =======, >>>>>>>), bearbeiten Sie den Inhalt, entfernen Sie die Markierungen, führen Sie git add für die gelösten Dateien aus und führen Sie git cherry-pick --continue aus. Wenn der Konflikt nicht gelöst werden kann — bricht git cherry-pick --abort den gesamten cherry-pick ab und setzt den Branch in seinen ursprünglichen Zustand zurück.

Ein häufiges Problem: der Commit enthält bereits Änderungen, die vorhandenen entsprechen. In diesem Fall meldet Git „nothing to commit“ oder „empty commit“ beim Versuch von cherry-pick. Die Flags --keep-redundant-commits und --empty=keep zwingen Git, einen leeren Commit zu erstellen, um die Sequenz beizubehalten, während --skip das Überspringen eines solchen Commits ermöglicht.

# Konflikt während cherry-pick — anhalten
git cherry-pick a1b2c3d
# error: konnte a1b2c3d... Commit-Nachricht nicht anwenden

# Konflikt lösen → zum Index hinzufügen
git add src/conflicted_file.swift
git cherry-pick --continue

# Leeren Commit überspringen (bereits angewendet)
git cherry-pick --skip

# Vollständiger Abbruch
git cherry-pick --abort

Beste Praktiken für cherry-pick

Erste Regel: Überprüfen Sie immer, dass der zu übertragende Commit in sich abgeschlossen ist. Wenn Commit A von Änderungen in Commit B abhängt, der nicht übertragen wird, kann cherry-pick von A den Build beschädigen. Vor dem cherry-pick ist es nützlich zu prüfen, welche Dateien der Commit geändert hat, mit git show --stat <hash>.

Zweite Regel: Dokumentieren Sie cherry-pick-Operationen. Verwenden Sie das Flag -x, damit die Commit-Nachricht einen Verweis auf den ursprünglichen Commit behält. Dies hilft bei der späteren Analyse der Historie, um zu verstehen, woher die Änderung stammt. Ohne -x sieht ein cherry-pick wie ein normaler Commit aus, und seine Herkunft kann nur über git log --graph bestimmt werden.

Dritte Regel: Vermeiden Sie cherry-pick zwischen Branches, die zu stark auseinandergegangen sind. Wenn seit der Erstellung des Commits viel Zeit vergangen ist und sich die Codebasis erheblich geändert hat, werden die Konflikte zahlreich und komplex sein. In solchen Fällen ist es besser, die Korrektur im Ziel-Branch neu zu implementieren — das dauert weniger Zeit als das Lösen Dutzender Konflikte.

• Cherry-pick nur in sich abgeschlossene Commits ohne externe Abhängigkeiten.
• Das -x Flag ist obligatorisch zur Dokumentation der Commit-Herkunft in der Nachricht.
• Vermeiden Sie cherry-pick von alten Commits mit großer Codebasis-Abweichung.
• CI/CD überprüfen Sie den Build nach cherry-pick: Ein Konflikt ist möglicherweise nicht aufgetreten, aber der Code könnte nicht kompilieren.
• PR-Kommentar geben Sie beim Erstellen eines Pull-Requests an, welche Commits per cherry-pick übertragen wurden.