git cherry-pick 是安全搬运指定 commit 的首选方案，支持单个、多个不连续或连续范围提交；配合 rebase -i 可合并多提交为一个再搬运，--patch 则实现文件级精细搬运。
git cherry-pick 合并单个或多个指定 commit
想把 feature 分支里某几个关键修复搬到 main，又不想带入其他无关改动？git cherry-pick 是最直接、最安全的选择。它不改变源分支历史，只把目标 commit 的变更“复制”成新 commit 落到当前分支。
常见错误现象：执行 git cherry-pick abc123 后提示 fatal: bad revision 'abc123' —— 说明 hash 输入错误，或该 commit 不在当前 git log 可见范围内（比如不在当前分支的祖先链上）。
- 先确认目标 commit 存在且可访问：
git log --oneline origin/feature或git log --oneline feature（如果本地没 fetch 过远程分支，得先git fetch） - 合并单个 commit：
git checkout main→git cherry-pick abc123def - 合并多个不连续 commit：
git cherry-pick abc123def 789xyz01 f2a4b5c6（顺序不影响应用结果，但冲突解决需按顺序来） - 合并连续范围（左开右闭）：
git cherry-pick a1b2c3^..d4e5f6→ 表示从a1b2c3的父提交开始，到d4e5f6结束（含d4e5f6）
git rebase -i 合并多个 commit 再整体 cherry-pick
源分支上有 5 个 commit，你只想挑其中 3 个合过去，但这 3 个不是连续的，且你希望它们在目标分支上变成一个干净的 commit？这时不能直接用 cherry-pick 多次——那会生成多个 commit。得先在源分支上整理好，再整体搬过去。
使用场景：修复类 patch 需要打包交付，或 PR 提交前清理历史。
- 切到源分支：
git checkout feature - 启动交互式变基：
git rebase -i HEAD~5（假设最近 5 个 commit 里有你要的） - 编辑器中把不需要的 commit 行标为
drop，把要保留的多个 commit 中除第一个外的都改成squash或fixup - 保存退出后，Git 会压缩成一个 commit，并打开编辑器让你重写 message
- 再切到目标分支：
git checkout main，然后git cherry-pick
注意：rebase -i 会改写本地分支历史，如果该分支已推送到远程且他人正在协作，就别这么干——改用 cherry-pick 单独搬更稳妥。
git checkout --patch 拆解式搬运单个文件的改动
有时你根本不需要整个 commit，只是想把 feature 分支里某个文件（比如 config.yaml）的几行修改挪到 main。这时候 cherry-pick 会连带搬来整个 commit 的所有文件改动，太重了。
参数差异：--patch 允许你交互式选择 hunk（代码块），比全量操作更精细。
- 确保已在目标分支：
git checkout main - 执行：
git checkout --patch feature -- config.yaml - Git 会逐块显示差异，输入
y应用、n跳过、s拆分 hunk、q退出 - 确认无误后，
git add config.yaml && git commit -m "cherry-pick config.yaml fix from feature"
容易踩的坑：这个命令不会自动创建 commit，它只是把改动“检出”到工作区，必须手动 git add 和 git commit 才算落地；另外，--patch 不支持通配符，每个文件得单独操作。
合并部分 commit 时冲突怎么处理才不丢改动
冲突不是失败信号，而是 Git 在提醒：“这段代码在两边都被改过，我没法自动判断哪个版本该保留”。cherry-pick 和 rebase 都会触发类似机制，但处理逻辑略有不同。
关键区别：cherry-pick 冲突后，解决完必须用 git add <file></file> 标记已解决，再 git cherry-pick --continue；而 rebase 冲突后同样要 git add，但继续命令是 git rebase --continue。
- 不要直接
git commit—— 这会生成普通 commit，破坏 cherry-pick/rebase 流程 - 冲突文件里看到的 >>>>>> abc123 是被 pick 的 commit 内容
- 改完保存后，用
git diff --staged确认 staging 区确实是你要的结果，再继续 - 万一搞砸了，
git cherry-pick --abort或git rebase --abort可退回原状
真正容易被忽略的是：cherry-pick 产生的新 commit 的 author 和 committer 信息默认是当前用户，但原始 commit 的 author 会被保留在 message 里（如 “(cherry picked from commit abc123)”），这对溯源很重要，别手工删掉。
