git cherry-pick wendet einen spezifischen Commit von einem Branch auf einen anderen an — kopiert nur die Änderungen dieses Commits, ohne den gesamten Branch zu mergen. Es ist nützlich, um selektiv bestimmte Änderungen anzuwenden, wie das Backporten einer Fehlerbehebung.
# apply a specific commit from another branch onto the current branch
git cherry-pick <commit-hash>
git cherry-pick <commit1> <commit2>
git cherry-pick A..B
Cherry-pick nimmt die Änderungen aus einem spezifischen Commit und wendet sie als neuen Commit auf deinen aktuellen Branch an — selektiv, ohne den Rest des Source-Branch zu übernehmen.
✓ BACKPORTING a fix — apply a bug fix from main to a release/maintenance branch
(without merging all of main's other changes into the release branch)
✓ Applying a specific commit that's ready, while the rest of its branch isn't
✓ Moving a commit made on the wrong branch to the correct one
✓ Selectively pulling one change from another branch
⚠️ Creates DUPLICATE commits (same changes, different hashes on each branch):
→ can cause confusion/conflicts if branches are later merged (the change appears twice,
though Git often handles it). Prefer merge/rebase for integrating whole branches.
⚠️ Cherry-picking many commits is a sign you might want a merge/rebase instead
⚠️ Conflicts can occur (resolve like a merge); use it deliberately, not as a default
→ Use cherry-pick for SELECTIVE, specific needs — not routine integration.
Das Verständnis von git cherry-pick ist wertvoll für das selektive Anwenden spezifischer Änderungen, eine nützliche Fähigkeit für bestimmte Situationen, daher ist es praktisches Git-Wissen, das es wert ist, bekannt zu sein.
Die Kernfähigkeit — Anwendung nur der Änderungen eines spezifischen Commits auf einen anderen Branch ohne Zusammenführung des gesamten Branch — adressiert echte Anforderungen, die das Mergen nicht sauber bewältigen kann.
Der häufigste und wichtigste Anwendungsfall ist das Backporting: Anwendung einer spezifischen Fehlerbehebung vom Hauptbranch auf einen Release- oder Wartungsbranch, um nur diese Fehlerbehebung zu erhalten, ohne alle anderen (möglicherweise instabilen oder unveröffentlichten) Änderungen des Hauptbranches in den Release-Branch zu mergen — ein häufiges Bedürfnis bei der Verwaltung freigegebener Software.
Andere Verwendungen umfassen das Anwenden eines einzelnen fertiggestellten Commits, während der Rest seines Branch noch nicht fertig ist, das Verschieben eines auf dem falschen Branch erstellten Commits auf den richtigen, und das selektive Abrufen einer Änderung.
Das Verständnis der Vorsichtsmaßnahmen ist wichtig für die angemessene Verwendung von cherry-pick: Es erstellt doppelte Commits (die gleichen Änderungen mit unterschiedlichen Hashes auf jedem Branch), was zu Verwirrung oder Konflikten führen kann, wenn die Branches später zusammengeführt werden, daher sollte es bewusst für selektive Anforderungen verwendet werden, anstatt als routinemäßige Integrationsmethode (Merge oder Rebase sind besser für die Integration ganzer Branches), und das Cherry-Picking vieler Commits ist ein Zeichen dafür, dass du wahrscheinlich stattdessen einen Merge möchtest.
Diese Beurteilung — cherry-pick für spezifische, selektive Situationen verwenden (besonders beim Backporting), während man Merge/Rebase für routinemäßige Integration bevorzugt — spiegelt gute Git-Praxis wider.
Da das selektive Anwenden spezifischer Änderungen (besonders das Backporten von Fehlerbehebungen auf Release-Branches) ein echtes, gelegentlich wichtiges Bedürfnis ist, und da cherry-pick das Werkzeug dafür ist (mit Vorsichtsmaßnahmen bezüglich seiner angemessenen Verwendung), ist das Verständnis von git cherry-pick — wie es funktioniert, seine Schlüsselanwendungsfälle wie Backporting, und wann man es gegenüber Merge/Rebase verwendet — wertvoll, praktisch relevantes Git-Wissen zur Bewältigung der selektiven Änderungsszenarien, die bei der Verwaltung und dem Verwalten von Software über Branches hinweg auftreten.