1. 项目概述：为什么 cherry-pick 是每个 Git 用户必须亲手“拧紧”的一把扳手

在真实世界的协作开发中，我见过太多团队把git merge当成万能胶水——所有分支都往主干上糊，结果主干越来越臃肿，历史越来越模糊，一个 bug 出现时，光是定位它在哪次合入时引入的，就要花掉半天时间。直到某天凌晨三点，线上服务突然报错，运维甩来一串日志，而你发现那个关键修复早在三天前就提交在feature/auth-refactor分支里，可那整个分支还远没到上线节奏。这时候，你不会想拉个 PR、走流程、等 CI、等 Review——你只想把那一行修复代码，干净利落地“拧”进release/v2.3分支里，立刻打补丁、发版本、睡觉。这就是git cherry-pick的真实战场：它不是教科书里的语法练习，而是生产环境里一把冷峻、精准、不讲情面的工程扳手。

它解决的从来不是“怎么用 Git”，而是“怎么在时间压力、分支割裂、历史碎片化的真实约束下，让代码变更以最小熵增的方式流动”。关键词不是“选择”，而是“隔离”；不是“复制”，而是“重演”；不是“搬运”，而是“重建”。它背后是一整套对 Git 对象模型的理解：commit 不是快照，而是指向 tree 和 parent 的指针；cherry-pick 不是拷贝文件，而是基于源 commit 的 patch，重新计算 diff、应用到当前 index、再生成一个新 commit——这个新 commit 拥有全新的 hash、全新的 author（默认是你）、全新的 parent（当前 HEAD），但它的 tree object 内容，与源 commit 的 tree object 在语义上完全一致。这种“同构异构”的特性，决定了它既强大又危险：你可以把它当作手术刀，也能把它用成电锯。我带过的十几个项目里，凡是把 cherry-pick 当作日常操作的团队，无一例外都建立了严格的 commit 粒度规范、强制的 commit message 模板和自动化 pre-commit 钩子；而那些把它当成“临时救火工具”随意使用的团队，半年后无一例外都在git log --graph里看到一片无法解读的“意大利面式”历史。所以这篇内容，不教你“怎么输入命令”，而是带你亲手拆解这把扳手的每一个齿纹、每一处应力点、每一次打滑时该往哪边借力——因为真正的 Git 熟练度，不在于你会多少命令，而在于你清楚每一次敲下回车时，Git 底层正在重写哪几个对象、修改哪几条引用、以及这个动作会在三个月后的某次git bisect中埋下怎样的伏笔。

2. 核心原理与设计逻辑：cherry-pick 不是复制，而是“重演式重建”

2.1 它到底在底层做了什么？三步不可跳过的对象级操作

很多教程说“cherry-pick 就是复制 commit”，这是最危险的误解。Git 里根本没有“复制 commit”这个操作。它实际执行的是一个严格定义的三阶段重建流程，每一步都直击 Git 的核心数据结构：

第一阶段：Patch 提取与上下文锚定
当你运行git cherry-pick abc1234，Git 首先做的不是读取abc1234这个 commit 对象本身，而是调用git show -p abc1234的等效逻辑，从该 commit 的 tree object 中，反向计算出它相对于其 parent commit 的完整 diff（即 patch）。这个 patch 不是简单的文本差异，而是包含精确的行号偏移、文件路径、二进制标识（对图片、字体等）的结构化变更描述。更重要的是，Git 会同时记录下这个 patch 所依赖的“上下文锚点”——即abc1234的 parent commit 的 tree hash。这个锚点至关重要：它告诉 Git，“我要应用的修改，是基于 parent 的某个特定文件树状态”。

第二阶段：Patch 应用与冲突检测
Git 接着将当前工作目录（即 target branch 的 HEAD）的 tree object 作为新的基线，尝试将上一步提取的 patch “贴”上去。这里的关键在于：Git 并不关心源 commit 的 parent 是谁，它只关心“这个 patch 在当前基线上是否还能干净地应用”。它会逐行比对 patch 中描述的“修改前内容”与当前文件的实际内容。如果完全匹配，就直接替换；如果不匹配（比如同一行被改过两次），就标记为冲突；如果 patch 要求删除一个当前不存在的文件，就报错。这个过程本质上是一次git apply --3way的变体，但强制要求三路合并（base, ours, theirs）中的 base 必须严格匹配源 commit 的 parent —— 这就是为什么 cherry-pick 在 diverged history 上极易失败的根本原因。

第三阶段：新 Commit 创建与引用更新
只有当 patch 全部成功应用（或冲突被手动解决并git add）后，Git 才进入最后一步：创建一个全新的 commit 对象。这个新 commit 的tree指向当前 index 的快照，parent指向当前 HEAD（即 target branch 的最新 commit），author默认设为你（git config user.name/email），committer也是你，但message会默认继承源 commit 的 message（除非你加-x或手动编辑）。最关键的是，它的 hash 是根据tree + parent + author + committer + message这五元组重新计算出来的，与abc1234完全无关。这意味着，即使 patch 内容 100% 相同，它在 Git 历史中就是一个彻头彻尾的“新人”，拥有自己独立的血缘和身份。

提示：你可以用git cat-file -p <new-commit-hash>查看新 commit 的完整内容，对比git cat-file -p abc1234，会清晰看到tree可能相同（如果无冲突），但parent、author、committer、hash全部不同。这才是 cherry-pick 的本质——一次受控的、带上下文验证的、生成新身份的变更重演。

2.2 为什么它比 merge/rebase 更“轻”，又更“脆”？

merge和rebase的设计目标是整合分支历史：merge 创建一个新 commit 同时指向两个 parent，保留双方历史；rebase 则是将一串 commit “重放”到新基线上，重写整个序列的 parent 关系。它们处理的是“一段历史流”。而cherry-pick的设计目标是移植单点变更，它刻意剥离了历史上下文，只抓取“变更本身”。这就造成了它独特的“轻-脆”二象性：

• 轻：因为它不关心源 commit 的 parent chain 是否完整。你完全可以 cherry-pick 一个来自已删除分支、甚至来自另一个仓库的孤立 commit，只要它的 patch 能在当前基线上应用。它不拖家带口，没有历史包袱，执行速度极快，内存占用极小。
• 脆：正因为它剥离了上下文，所以它极度脆弱于“隐式依赖”。比如，源 commitabc1234修复了一个空指针异常，但它之所以能编译通过，是因为abc1233引入了一个新的工具函数。如果你只 cherry-pickabc1234，而abc1233并未存在于 target branch，那么新 commit 很可能直接编译失败——Git 的冲突检测机制对此完全无感，因为它只检查文件内容行，不检查符号定义。这种“逻辑依赖断裂”是 cherry-pick 最隐蔽也最致命的坑。

我曾在一个微服务项目里踩过这个坑：前端团队提交了一个 UI 组件的样式修复（commit A），但这个修复依赖于后端 API 返回的一个新字段（commit B）。他们只 cherry-picked A 到预发环境，结果页面白屏。查了两小时才发现是后端字段缺失。从此我们团队的 cherry-pick SOP 第一条就是：“单个 commit 的 cherry-pick，必须附带git log -n 5 abc1234的上下文截图，并由源分支负责人签字确认无隐式依赖”。

2.3 三种核心模式：单点、区间、交互——选错模式等于自断一臂

cherry-pick 的语法看似简单，但不同模式触发的是 Git 完全不同的内部状态机，选错模式会导致事倍功半：

• 单点模式 (git cherry-pick <hash>)：最常用，也最安全。Git 进入“单次应用”状态，成功则立即创建新 commit，失败则停在冲突态。适合明确知道只需一个变更的场景，如热修复。
• 区间模式 (git cherry-pick A..B)：这是最容易被误解的。A..B表示“B 可达的所有 commit，减去 A 可达的所有 commit”，即从 A 的下一个 commit 开始，到 B（包含）为止。它不是“从 A 到 B 的线性路径”，而是 Git 的 DAG（有向无环图）遍历结果。如果 A 和 B 有多个共同祖先，这个区间可能包含大量你意想不到的 commits。实测下来，我建议永远用git cherry-pick A^..B（A 的父节点到 B）来确保线性，或者直接用git log --oneline A^..B先预览。
• 交互模式 (git cherry-pick -i <range>)：这才是处理复杂场景的王者。它会启动一个类似git rebase -i的编辑器，列出所有待 pick 的 commits，你可以对每一行执行pick/drop/edit/reword。edit是神技：它会在应用该 commit 后暂停，让你修改代码、修改 message、甚至git commit --amend，然后再git cherry-pick --continue。这解决了“需要微调再提交”、“需要分拆大 commit”、“需要修正 author 信息”等所有高阶需求。很多团队不知道这个模式，硬生生把 cherry-pick 用成了“半自动 copy-paste”，效率损失巨大。

注意：git cherry-pick -n（no-commit）常被误认为是交互模式，其实它只是禁用自动提交，仍属单点模式。它适合“应用+修改+手动 commit”的短流程，但无法处理多 commit 的精细控制。真正需要灵活调度时，-i才是唯一正解。

3. 实操全流程与关键细节：从准备到收尾的每一步都藏着经验

3.1 操作前的黄金三分钟：不做这三件事，90% 的失败源于此

在敲下第一个git cherry-pick之前，我强制自己执行一个三分钟检查清单。这不是仪式，而是基于血泪教训的防御性编程：

第一步：确认源 commit 的“纯净度”（2 分钟）
不要只看git log --oneline。运行：

git show --stat abc1234 # 看它到底改了哪些文件，范围是否合理？ git show --pretty=fuller abc1234 # 看 author/committer 是否可信？message 是否清晰说明意图？ git log -n 5 --oneline abc1234^ # 看它的前 5 个 parent，有没有可疑的 merge commit 或大 refactoring？

重点检查--stat输出。如果它显示修改了 20 个文件，其中 18 个是package-lock.json或yarn.lock，那这个 commit 极大概率是“环境污染”，不该 cherry-pick。真正的修复 commit，应该聚焦在 1-3 个核心业务文件上。

第二步：同步目标分支到最新状态（30 秒）
永远假设你的本地 target branch 是陈旧的。执行：

git checkout main git pull --ff-only # 强制快进，拒绝 merge commit！如果失败，说明有本地未 push 的提交，先处理它。

--ff-only是关键。它确保你是在一个干净、最新的基线上操作。如果pull失败，说明你本地有未推送的提交，此时必须先git push或git reset --hard origin/main（谨慎！），绝不能带着本地脏历史去 cherry-pick，否则新 commit 的 parent 会指向一个只存在于你本地的 commit，造成后续协作灾难。

第三步：创建临时备份分支（30 秒）

git checkout -b cherry-pick-backup-$(date +%s) # 例如 cherry-pick-backup-1715678901

这行命令成本几乎为零，但它能在你cherry-pick --abort后，瞬间找回原始状态。我见过太多人--abort后发现工作区被污染，只能git reset --hard丢弃所有未暂存修改，结果连自己刚写的调试代码都丢了。一个带时间戳的备份分支，就是你的后悔药。

3.2 单点 cherry-pick：从找到 hash 到完成提交的完整链路

假设你要把feature/login分支上的一个密码强度校验修复（hasha1b2c3d）应用到main。以下是我在终端里实际执行的、带注释的完整流程：

# 1. 切换到源分支，精确定位 commit（避免在错误分支上 git log） $ git checkout feature/login $ git log --oneline -n 10 | grep "password\|strength" a1b2c3d (HEAD -> feature/login) fix: improve password strength validation regex # 2. 切换到目标分支，并确保最新（黄金三分钟第二步） $ git checkout main $ git pull --ff-only From github.com:org/repo * branch main -> FETCH_HEAD Already up to date. # 3. 执行 cherry-pick（此时 Git 会自动创建新 commit） $ git cherry-pick a1b2c3d [main 789ef01] fix: improve password strength validation regex Author: Alice <alice@org.com> Date: Mon May 13 14:22:33 2024 +0800 1 file changed, 2 insertions(+), 1 deletion(-) # 4. 验证结果（关键！不能只信 Git 的 success message） $ git show --stat 789ef01 # 确认修改的文件和行数与 a1b2c3d 一致 $ git diff HEAD~1 HEAD # 看新 commit 与前一个 commit 的差异，是否就是预期的两行修改？ $ npm test # 运行相关测试，确保逻辑正确（很多团队跳过这步，导致 bug 漏网）

实操心得：

• git show --stat是我的每日必检项。它比git log更直观，一眼看出这个 cherry-pick 是否“偷懒”地包含了不该有的文件（比如.idea/配置）。
• git diff HEAD~1 HEAD这个技巧很多人不知道。它直接对比新 commit 与它父 commit 的差异，相当于在验证“这个新 commit 是否真的只包含了我想要的变更”，而不是 Git 自动塞进去的其他东西。
• 测试不是可选项。我规定团队所有 cherry-pick 后必须运行npm test或对应语言的测试命令，CI 会卡住未测试的 PR。因为 cherry-pick 的 patch 应用是纯文本的，它无法保证语义正确性。

3.3 区间 cherry-pick：如何安全地搬运一串连续的 commits

场景：feature/payment分支上，你提交了 5 个 commits（p1->p2->p3->p4->p5），现在需要全部搬到release/v3.0。错误做法是git cherry-pick p1 p2 p3 p4 p5——这会按你输入的顺序应用，但如果p2依赖p1的修改，而p1还没应用，就会失败。正确做法是使用区间，并严格按拓扑序：

# 1. 在源分支上，用 --graph 确认线性顺序（关键！） $ git checkout feature/payment $ git log --graph --oneline --simplify-by-decoration -n 10 * a5f6b7c (HEAD -> feature/payment) p5: update payment gateway docs * d4e5f67 p4: add retry logic for network timeout * c3d4e5f p3: refactor payment service interface * b2c3d4e p2: fix currency conversion rounding * a1b2c3d p1: initial payment integration # 2. 记住第一个（p1）和最后一个（p5）的 hash # 3. 切换到目标分支，确保最新 $ git checkout release/v3.0 $ git pull --ff-only # 4. 使用正确的区间语法：p1^..p5 （注意 ^ 符号！） # p1^ 表示 p1 的父节点，p1^..p5 表示从 p1 开始到 p5（包含） $ git cherry-pick a1b2c3d^..a5f6b7c [release/v3.0 123abcd] p1: initial payment integration Author: Bob <bob@org.com> 2 files changed, 15 insertions(+) [release/v3.0 234bcde] p2: fix currency conversion rounding Author: Bob <bob@org.com> 1 file changed, 3 insertions(+), 1 deletion(-) # ... 依此类推，Git 会按 p1->p2->p3->p4->p5 的顺序依次应用

为什么必须用p1^..p5？
因为p1..p5的含义是“p5 可达但 p1 不可达的所有 commits”，如果 p1 和 p5 有共同祖先，这个集合可能为空或包含无关 commits。而p1^..p5明确表示“从 p1 的父节点之后开始，到 p5 结束”，这才能保证得到 p1 到 p5 的完整线性序列。这是我从 Git 源码注释里抠出来的细节，官方文档都没写这么细。

3.4 交互式 cherry-pick：处理“需要微调”的高级场景

场景：feature/i18n分支上有一个 commiti1，它添加了英文翻译，但你需要在中文分支上应用时，把en.json的内容替换成zh.json的对应键值。-n模式不够用，必须用-i：

$ git checkout zh-CN $ git pull --ff-only $ git cherry-pick -i i1 # Git 启动编辑器，显示： # pick i1 add english translation strings # 保存退出（默认就是 pick） # Git 开始应用 i1，然后暂停（因为 -i 模式） # 此时，index 里已经有了 i1 的变更（en.json 被修改） # 但还没有 commit！ # 1. 手动编辑文件，替换内容 $ vim src/locales/zh.json # 把 en.json 里的 "login": "Login" 改成 "login": "登录" # 2. 重新 stage 修改后的文件 $ git add src/locales/zh.json # 3. 修改 commit message，注明是中文适配 $ git commit --amend -m "chore(i18n): add chinese translation strings (cherry-picked from i1)" # 4. 继续流程（此时只有一个 commit，所以直接完成） $ git cherry-pick --continue [zh-CN 890def1] chore(i18n): add chinese translation strings (cherry-picked from i1) Author: You <you@org.com> 1 file changed, 10 insertions(+)

实操心得：

• git commit --amend是-i模式的灵魂伴侣。它让你在 cherry-pick 过程中，拥有对新 commit 的完全控制权：改 message、改 author、改 content，毫无限制。
• 如果你--amend后忘了--continue，Git 会一直卡在“rebase in progress”状态。此时git status会明确提示You are currently cherry-picking commit i1.，按提示操作即可。
• -i模式下，编辑器里可以对任意一行改成drop来跳过某个 commit，改成reword来只修改 message，这比--skip精细得多。

4. 冲突处理与疑难排障：那些文档里不会写的“现场急救指南”

4.1 冲突发生的底层真相：不是“代码打架”，而是“上下文失配”

当git cherry-pick报出CONFLICT (content): Merge conflict in file.js，新手第一反应是“哎呀，两段代码改了同一行”。但资深用户会立刻问三个问题：

1. 这个冲突行，在源 commit 的 patch 里，它的“上下文行”是什么？
   运行git show -U1 i1（-U1表示显示 1 行上下文），找到冲突位置附近的@@ -X,Y +A,B @@行，看+A,B里的A（起始行号）和B（行数）。这告诉你，Git 期望在目标文件的第 A 行附近找到它要修改的“原样”内容。

2. 当前目标文件的第 A 行附近，实际内容是什么？
   用head -n $((A+2)) file.js | tail -n 3查看。如果这里的内容与 patch 里期望的“原样”完全不同，说明不是“两人都改了”，而是“目标文件的结构已经变了”，比如函数被重命名、模块被拆分。

3. 这个冲突，是“真冲突”还是“假冲突”？
   “真冲突”：两段逻辑确实矛盾，必须人工抉择。
   “假冲突”：只是 Git 的行号匹配算法失效了。比如源 patch 要在第 100 行插入，但目标文件因为前面删了 5 行，现在第 100 行其实是源文件的第 95 行。这时，你应该手动把要插入的内容，放到目标文件逻辑上正确的位置（比如现在的第 95 行），然后git add。

提示：git diff --cached是冲突解决后的必检项。它显示的是“即将被 commit 的内容”，也就是你git add后的最终结果。运行它，确认输出里只有你期望的、干净的变更，没有残留的<<<<<<<标记或意外的其他修改。这是防止“冲突解决不彻底”导致线上 bug 的最后一道防线。

4.2 五种典型冲突场景与我的“秒解”方案

4.3 那些让人抓狂的“幽灵问题”与终极排查法

问题：git cherry-pick abc1234报错fatal: bad revision 'abc1234'
这通常不是 hash 错了，而是你的本地仓库根本没见过这个 commit。解决方案三步走：

1. git fetch --all --prune：拉取所有远程分支的最新引用，清理已删除的远程跟踪分支。
2. git branch -r \| grep abc1234：看这个 hash 是否出现在某个远程分支名里（如origin/feature/x）。
3. 如果没找到，运行git reflog --all \| grep abc1234：reflog记录了你本地所有操作的历史，包括已删除分支的 commit，只要没被 GC，就能捞回来。

问题：cherry-pick 成功了，但功能没生效，或者出现奇怪 bug
这 90% 是“隐式依赖”或“环境差异”导致。我的排查 checklist：

• git show abc1234：确认源 commit 的treehash。
• git show 789ef01（新 commit）：确认它的treehash 是否与源 commit 的treehash完全一致？如果不一致，说明 patch 应用时有冲突未解决干净，或你手动改错了。
• git diff abc1234 789ef01：这个命令会比较两个 commit 的 tree 内容。如果输出为空，说明内容 100% 一致；如果有输出，说明 cherry-pick 过程中发生了意料之外的修改（比如自动换行符转换、IDE 自动格式化）。
• git log --oneline -n 20 --all --grep="keyword"：用源 commit message 里的关键词，在所有分支搜索，看这个逻辑是否已在别处以不同形式存在。

问题：不小心 cherry-pick 了错误的 commit，已经git push了怎么办？
绝对不要git reset --hard然后push -f！这会破坏所有协作者的本地历史。正确做法：

1. git revert 789ef01：创建一个新 commit，内容是789ef01的逆向操作。这是 Git 官方推荐的、安全的“撤回”方式。
2. git push origin main：推送 revert commit。所有人都会看到一个清晰的 “Revert "fix: ..."” 提交，历史可追溯、可理解。
3. 如果 revert 后发现还有其他问题，可以继续git revert <revert-commit-hash>，形成 revert 链。Git 的设计哲学是“历史只增不减”，revert 就是它的优雅体现。

5. 工程实践与避坑指南：让 cherry-pick 从“救火工具”变成“标准流程”

5.1 团队级 SOP：我们如何把 cherry-pick 变成可审计、可追溯的工程动作

在我负责的支付网关项目里，cherry-pick 不是一个开发者个人行为，而是一套嵌入 CI/CD 的标准化流程。核心原则是：任何 cherry-pick 都必须产生可验证、可回溯、可归责的工件。具体 SOP 如下：

Step 1：申请与审批（Jira Issue）

• 创建 Jira issue，标题为[CHERRY-PICK] <source-branch> -> <target-branch>，例如[CHERRY-PICK] feature/refund -> release/v3.1。
• Description 必须包含：
  • 源 commit hash 列表（用git log --oneline <range>输出）
  • 每个 commit 的git show --stat <hash>截图
  • 一句话说明“为什么不能 merge 整个分支？”（必须是业务原因，如“该分支包含未验收的风控规则”）
  • 预期影响范围（修改了哪些 API、哪些数据库表）
• Assignee 为源分支负责人，他必须评论 “Approved: no hidden dependencies, safe to pick” 才能进入下一步。

Step 2：自动化预检（GitHub Action）
我们编写了一个自定义 Action，当 PR 的 title 包含[CHERRY-PICK]时自动触发：

• 检查所有 listed hashes 是否存在于origin/<source-branch>。
• 运行git cherry-pick -n <hash>并git diff --cached，确保无意外变更。
• 运行npm test和npm run lint。
• 最关键的检查：git log --oneline --all --grep="<commit-message-keyword>" \| wc -l，如果返回 >1，说明该逻辑已在其他地方存在，阻止 PR。
  只有所有检查通过，PR 才能被 approve。

Step 3：执行与记录（Commit Message 模板）
批准后，执行 cherry-pick 的开发者必须使用以下 commit message 模板：

chore(cherry-pick): <original-message> - Source: <source-branch>@<hash> - Target: <target-branch> - Reason: <business-reason-from-jira> - Verified: <test-results-summary>

例如：

chore(cherry-pick): fix: prevent double charge on network timeout - Source: feature/refund@b2c3d4e - Target: release/v3.1 - Reason: This fix is critical for production stability and cannot wait for full feature release. - Verified: All refund e2e tests pass, manual smoke test on staging successful.

这个模板被 CI 强制校验，缺少任一字段，git commit会失败。它让未来的git blame或git log能瞬间还原整个 cherry-pick 的上下文。

5.2 个人避坑清单：那些让我少加班 200 小时的“血色笔记”

• “永远不要 cherry-pick merge commit”：Merge commit 的 patch 是空的（它不引入新变更，只连接历史），cherry-pick 它只会创建一个无意义的新 commit，还可能破坏目标分支的线性。如果需要 merge 的效果，请直接git merge。
• “cherry-pick 后，立刻git push，不要积压”：我见过最惨的案例是开发者 cherry-pick 了 5 个 hotfix，本地存了三天，期间main分支被其他人force-push重写了历史，导致他的 5 个新 commit 的 parent 全部失效，git push直接被拒绝，只能全部revert重来。
• “对--no-commit的迷信是最大的陷阱”：很多人觉得-n很安全，可以慢慢改。但-n模式下，Git 不会帮你 resolve conflicts，它只是不 commit。如果你在-n状态下git add了冲突文件，然后git commit，Git 会把冲突标记（<<<<<<<）一起 commit 进去！这比直接失败更可怕。所以-n只适用于“100% 确信无冲突且只需微调”的场景。
• “git cherry-pick --abort不是万能的”：--abort只能恢复到 cherry-pick 开始前的状态，但它不会恢复你git add过的、但尚未 commit 的修改。所以，一旦开始 cherry-pick，就不要再git add任何与之无关的文件。我的习惯是：cherry-pick前，先git status，确保工作区干净；如果必须有未提交修改，先git stash。
• “-x参数不是‘保持原作者’，而是‘标注来源’”：git cherry-pick -x abc1234会在新 commit message 末尾自动加上(cherry picked from commit abc1234)。它不会改变author字段（author 还是你），它只是加了一行引用。真正的“保持原作者”要用git cherry-pick --author="Alice <alice@org.com>" abc1234，但这在团队协作中极少用，因为 commit 的committer（执行 cherry-pick 的人）才是责任主体。

5.3 替代方案评估：什么时候该放下 cherry-pick，转身去用 merge 或 rebase？

cherry-pick 不是银弹。在以下场景，强行使用它，代价远高于收益：

• 场景一：需要搬运超过 5 个 commits，且它们之间有强依赖
  例如，一个 feature 分支有 10 个 commits，从环境配置、到核心逻辑、再到 UI 层，层层递进。此时 cherry-pick 10 个，要处理 9 次潜在的隐式依赖冲突。正确做法：为这个 feature 创建一个临时 release 分支（如release/feature-x），git merge feature/x进去，然后 `