Cherry-Picking: wann es passt und was es die Historie kostet

Worum es geht

git cherry-pick <commit> wendet die Änderung, die ein Commit einführt, auf den aktuellen Branch an und zeichnet einen neuen Commit auf. Die Dokumentation verlangt einen sauberen Arbeitsbaum, hält bei Konflikten an, wobei CHERRY_PICK_HEAD bis zu --continue, --skip oder --abort gesetzt bleibt, und bietet -x an, um der Nachricht eine Zeile "(cherry picked from commit ...)" anzuhängen. Das Picken eines Merge-Commits braucht -m <parent-number>, um festzulegen, welcher Elternteil die Hauptlinie ist. -n / --no-commit wendet mehrere Picks in den Index an, bevor ein einziger Commit erstellt wird.

Warum es wichtig ist

Der neue Commit hat denselben Patch, aber eine andere ID und einen anderen Elternteil. Git vergleicht Commits nach Abstammung, daher weiss ein späterer Merge des Quell-Branches nicht, dass die Änderung bereits vorhanden ist: Eine identische Änderung auf beiden Seiten merged meist sauber, aber jeder Unterschied (ein während des Picks aufgelöster Konflikt, eine spätere Bearbeitung derselben Zeilen) wird zum Konflikt, und die Historie behält in jedem Fall zwei Commits für eine Änderung. Jedes Pick fügt daher einen kleinen, dauerhaften Preis hinzu: Historie, die über den Patch-Inhalt statt über die Abstammung abgeglichen werden muss. git log --cherry-pick --left-right A...B existiert genau deshalb, um Commits auszulassen, die auf der anderen Seite dieselbe Änderung einführen, wie die git-log-Dokumentation beschreibt.

So wird es angewendet

• Beim Zurückportieren eines Fixes: den Fix auf dem ältesten unterstützten Branch committen und nach oben mergen, oder ihn mit -x nach unten picken, damit der Ursprung nachvollziehbar bleibt. Die Dokumentation empfiehlt -x für Picks zwischen öffentlichen Branches und rät bei privaten davon ab.
• Um einen einzelnen guten Commit aus einem Branch zu retten, der verworfen wird: ihn picken und danach den Branch löschen, damit keine doppelte Abstammungslinie zurückbleibt.
• Wird ein ganzer Branch gewollt: mergen oder rebasen. Jeden Commit eines Branches zu picken erzeugt eine zweite Abstammungslinie derselben Änderungen, die ein späterer Merge nicht als bereits integriert erkennen kann.
• Ein aus einem Release-Branch veröffentlichter Hotfix: sofort in main picken, bevor die beiden weiter auseinanderdriften.
• Gepickte Commits klein und in sich geschlossen halten; das Picken der Hälfte eines Refactorings führt später bei der anderen Hälfte zu Konflikten.

Stolpersteine

Das Picken eines Commits, der von früheren, nicht gepickten Commits abhängt, kompiliert nur durch Zufall oder gar nicht. Die Konfliktlösung während eines Picks wird nirgends ausser im neuen Commit festgehalten. Das Bisektieren eines aus Picks bestehenden Branches zeigt auf die Kopie, nicht auf die ursprüngliche Diskussion, sofern keine -x-Zeilen vorhanden sind. Wiederholte Picks zwischen langlebigen Branches sind ein Zeichen dafür, dass das Branching-Modell geändert werden muss, nicht das Werkzeug.