应使用 git cherry-pick 而非 git merge 来挑选单次提交，它复制变更生成新提交，适用于修复、小功能等独立操作；需注意依赖关系、提交顺序、范围语法、冲突解决及签名作者信息差异。
直接用 git cherry-pick，别用 git merge —— 后者是合并整个分支历史，不是“挑一次提交”该做的事。
cherry-pick 选中单个提交最稳
它把目标提交的变更内容复制到当前分支，生成一个新提交（哈希不同，但改动一致）。适合修复、小功能、紧急补丁这类独立性强的操作。
- 必须先
git checkout到你想合入的目标分支（比如main），再执行cherry-pick - 提交哈希要准确：用
git log --oneline feature-branch查，别凭记忆或截图抄错位数 - 如果目标提交依赖前序改动（比如它改了函数 A，而函数 A 是上一个提交才加的），
cherry-pick会失败或行为异常——这时不是命令问题，是逻辑不可拆分 - 成功后，
git log --oneline -3能立刻看到新提交在最顶上，父提交仍是原分支 HEAD
合并多个不连续提交要小心顺序
git cherry-pick a1b2c3 d4e5f6 g7h8i9 会按命令里从左到右的顺序依次应用。如果 d4e5f6 依赖 g7h8i9 的改动，就会冲突甚至编译失败。
- 推荐分多次执行，每次
git cherry-pick后确认测试通过再继续 - 想跳过某个中途出错的提交？用
git cherry-pick --skip，但得清楚跳过后整体逻辑是否还成立 - 别用
git cherry-pick -x往生产分支打补丁——它会在提交信息末尾自动加(cherry picked from commit ...)，暴露来源分支名，有安全或合规风险
连续范围提交用 ^.. 语法，注意开闭区间
git cherry-pick a1b2c3^..d4e5f6 表示“从 a1b2c3 的父提交开始，到 d4e5f6（含）为止的所有提交”。这个 ^ 容易漏掉，漏了就变成只 pick d4e5f6 本身。
- 验证范围是否正确：先跑
git log --oneline a1b2c3^..d4e5f6，看输出是不是你想要的那几条 - 如果 a1b2c3 是第一个提交（没有父提交），
a1b2c3^会报错；此时改用git cherry-pick --no-commit a1b2c3 d4e5f6手动控制 - 范围跨太多提交时，
cherry-pick可能触发大量冲突；不如建临时分支切出这段历史，再rebase --onto，更可控
冲突不是失败，但解决后必须 git add 再 cherry-pick --continue
冲突文件里出现的 、<code>=======、>>>>>> a1b2c3 是 Git 标记，删掉它们只是第一步。
- 真正关键的是：保留哪边逻辑、要不要合并两段、要不要重写——这没标准答案，得看业务语义
- 改完保存后，必须对每个冲突文件执行
git add <file></file>，否则--continue会报错：“you must edit all merge conflicts and then mark them as resolved using git add” - 误操作想撤回？
git cherry-pick --abort会清空所有已解决状态，回到 pick 前；如果只解决了一半，先git status看哪些已added，心里有数再 abort
最容易被忽略的点：cherry-pick 生成的新提交，和原提交的 GPG 签名、作者信息、时间戳都不同。如果你的 CI/CD 流水线校验提交签名，或者审计要求追溯原始 author，就得额外处理 --signoff 或 --allow-empty 等参数，不能默认一用了之。
