git cherry-pick 将一个特定提交从一个分支应用到另一个分支——仅复制该提交的更改，而不合并整个分支。它对于选择性地应用特定更改（如回溯一个修复）很有用。
# apply a specific commit from another branch onto the current branch
git cherry-pick <commit-hash>
# → creates a NEW commit on the current branch with that commit's changes
# (a copy — new hash, same changes)
git cherry-pick <commit1> <commit2> # multiple commits
git cherry-pick A..B
Cherry-pick 从一个特定提交中获取更改，并将其作为新提交应用到您的当前分支——选择性地，不带上源分支的其余部分。
✓ 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.
理解 git cherry-pick 对于选择性应用特定更改很有价值，这是特定情况下的一个有用能力，因此是值得了解的实用 Git 知识。
核心能力——将特定提交的更改应用到另一个分支而不合并整个分支——解决了合并无法处理的真实需求。
最常见和最重要的用途是回溯：将主分支中的特定错误修复应用到发布或维护分支，仅获得该修复而不将主分支的所有其他（可能不稳定或未发布的）更改合并到发布分支——这是维护已发布软件的常见需求。
其他用途包括在其分支的其余部分未准备好时应用单个已准备的提交、将在错误的分支上创建的提交移动到正确的分支，以及选择性地拉取一个更改。
理解注意事项对于恰当地使用 cherry-pick 很重要：它创建重复提交（每个分支上具有不同哈希的相同更改），如果之后合并分支，可能会导致混淆或冲突，因此应该有意地用于选择性需求而不是作为常规集成方法（merge 或 rebase 更适合集成整个分支），cherry-pick 许多提交是一个信号，表明您可能想要合并。
这种判断——在特定、选择性的情况下（特别是回溯）使用 cherry-pick，同时对于常规集成更倾向于使用 merge/rebase——反映了健全的 Git 实践。
由于选择性应用特定更改（特别是向发布分支回溯修复）是真实的、偶尔很重要的需求，并且 cherry-pick 是实现它的工具（带有关于其适当使用的注意事项），理解 git cherry-pick——它如何工作、它的关键用例（如回溯）以及何时相对于 merge/rebase 使用它——是有价值的、切实相关的 Git 知识，用于处理在跨分支维护和管理软件时出现的选择性更改场景。