Git Cherry-Pick: Mehrere Commits, Branches, Konflikte

TL;DR: git cherry-pick <sha> kopiert einen Commit aus einem beliebigen Branch auf deinen aktuellen — derselbe Patch, neue SHA, keine History wird verschoben. Bei mehreren Commits: SHAs auflisten oder eine Range nehmen (git cherry-pick A..B); die Range schließt A aus, schreibe also A^..B, um ihn einzuschließen. Stoppt es an einem Konflikt: lösen, git add, dann git cherry-pick --continue. Cherry-Picking ist dafür da, einen bestimmten Fix zu verschieben — willst du alles vom anderen Branch, nimm merge oder rebase.

Was macht git cherry-pick eigentlich?

Cherry-pick nimmt einen existierenden Commit und wendet seinen Diff als neuen Commit auf deinem aktuellen Branch an. Der Original-Commit bleibt, wo er ist; die Kopie bekommt eine frische SHA. Git „verschiebt” nichts — wer sich später wundert, warum der Commit immer noch auf dem alten Branch auftaucht, sieht genau das.

Dieses Kopieren-statt-Verschieben-Modell entscheidet, wann cherry-pick das richtige Werkzeug ist:

• Du brauchst einen Fix aus einem Feature-Branch jetzt auf main, ohne den Rest zu mergen.
• Ein auf dem falschen Branch gelandeter Hotfix muss auf den richtigen.
• Ein Patch muss auf einen Release-Branch gespielt werden, der nie aus main merged.

Die ergänzende Fertigkeit ist, einen als falsch entpuppten Commit wieder herauszunehmen — die Mechanik dazu steht in git undo last commit: keep the changes.

Wie pickt man einen Commit aus einem anderen Branch?

SHA suchen, auf den Ziel-Branch wechseln, picken:

# 1. Den Commit auf dem Quell-Branch finden
git log feature/payment-fix --oneline -5

# 2. Auf den Branch wechseln, der ihn empfangen soll
git switch main

# 3. Rüberkopieren
git cherry-pick 1a2b3c4

Zwei Annehmlichkeiten, die man kennen sollte:

• git cherry-pick <branch> pickt den Tip-Commit dieses Branches — praktisch, aber leicht aus Versehen, wenn das mentale Modell davon, was „der Tip” ist, veraltet ist.
• Nach dem Pick bestätigt git log -1 --stat, was gelandet ist. Eine Sekunde Lesen, spart einen Revert.

Die Commits bleiben auf feature/payment-fix; den Branch darfst du löschen, wann du willst — die gepickte Kopie auf main hat eine eigene SHA und keine Abhängigkeit zur alten.

Wie pickt man mehrere Commits?

Drei Formen, sortiert danach, wie oft du sie willst:

# 1. Explizite Liste — gepickt in der Reihenfolge der Nennung
git cherry-pick 1a2b3c4 5d6e7f8

# 2. Range — alles nach A bis einschließlich B
git cherry-pick A..B

# 3. Range inklusive A
git cherry-pick A^..B

Der A..B-gegen-A^..B-Unterschied ist die klassische Überraschung: A..B schließt A aus. Visualisierst du die Range aus git log und pickst oldest..newest, überspringst du stumm den ältesten Commit. Wenn „die ältesten paar Commits, in Reihenfolge” das Ziel ist, schreibe oldest^..newest, und der Off-by-one verschwindet.

Um mehrere Picks in einen Commit statt in drei zu falten, stage mit -n / --no-commit ohne zu committen, dann committe einmal:

git cherry-pick -n 1a2b3c4 5d6e7f8
git commit -m "Backport: payment retry fixes"

Warum funktioniert git cherry-pick nicht?

Vier echte Ursachen, nach Häufigkeit:

1. Ein Konflikt hat den Pick gestoppt. Git wendet den Patch an, trifft auf eine Zeile, die sich auf beiden Branches geändert hat, und pausiert mitten in der Sequenz:

# die Dateien auflösen, dann:
git add <resolved-files>
git cherry-pick --continue   # oder --abort, um zurück in den Zustand vor dem Pick zu kommen

--continue ist nicht optional und nicht implizit — bis du es ausführst, steckst du in einer pausierten Cherry-Pick-Sequenz, und git status wird dir das immer wieder sagen.

2. Der Pick ist leer („The previous cherry-pick is now empty”). Die Änderung existiert auf diesem Branch bereits, oft durch einen früheren Pick oder ein gesquashtes Merge. Überspringe mit git cherry-pick --skip, oder erzwinge einen leeren Commit mit --allow-empty, wenn du die Markierung wirklich brauchst.

3. Der Commit ist ein Merge-Commit. Ein Merge hat zwei Parents, also ist „diesen Diff anwenden” mehrdeutig — git verweigert, statt zu raten. Sag, gegen welchen Parent du differierst:

git cherry-pick -m 1 <merge-sha>   # Parent 1 = der Branch, in den gemerged *wurde*

4. Falscher Working Tree oder detached HEAD. Der Pick landet, wohin HEAD zeigt. git branch --show-current vor dem Picken; gibt es nichts aus, bist du im detached HEAD, und der Commit wird verwaist, sobald du wechselst.

Cherry-pick vs. merge vs. rebase: was wofür?

Befehl	Was auf dem Ziel landet	History	Einsetzen, wenn
git cherry-pick <sha>	Nur die genannten Commits	Kopie, neue SHAs	Ein bestimmter Fix muss jetzt rüber
git merge <branch>	Alles auf dem Branch	Merge-Commit oder Fast-Forward	Du willst den ganzen Branch, Divergenz sichtbar
git rebase <base>	Alle Branch-Commits, wiederaufgespielt	Linear, umgeschriebene SHAs	Du willst den Branch als saubere lineare Folge
git revert <sha>	Das Inverse eines Commits	Fügt einen Undo-Commit an	Ein gelandeter Commit muss auf geteilter History rückgängig gemacht werden

Die Einzeiler-Regel: Cherry-pick verschiebt eine Auswahl; merge und rebase verschieben alles. Nach cherry-pick zu greifen, um sich mit einem Branch zu „synchronisieren”, ist ein Zeichen, dass du eigentlich ein Merge willst — und geht es um den main deines Forks gegen upstream, steht die komplette Routine in sync a fork with upstream, step by step.

Eine Angewohnheit zum Streichen: denselben Commit dauerhaft in mehrere Branches zu picken. Jeder künftige Fix auf dem Quell-Branch braucht einen weiteren Pick, und irgendwann driften die Branches auseinander. Backports auf Release-Branches sind ein normales Muster; ein permanentes Paralleluniversum ist keins.

Der Cherry-Pick-Workflow, komprimiert

git log <source-branch> --oneline -5   # die(n) SHA(s) finden
git switch <target-branch>             # am richtigen Ort landen
git cherry-pick A^..B                  # Range, Liste oder einzelne SHA
# bei Konflikt: lösen → git add → git cherry-pick --continue
git log -1 --stat                      # prüfen, was gelandet ist

Finden, wechseln, picken, prüfen. Der Befehl hat einen Ruf als Gefahr, den er nicht verdient — der Diff wird entweder angewendet oder er stoppt und sagt dir warum. Der einzige wirklich destruktive Fehler ist das Picken in den falschen Branch, und ein git log -1 vor dem Push macht den schwer zu übersehen.