用 git cherry-pick 可将指定提交的改动在当前分支重演并生成新 commit；需先切换至目标分支，确保工作区干净，避免误操作源分支或 merge commit。
怎么用 git cherry-pick 合并单条 commit
直接切到目标分支，执行 git cherry-pick <commit-hash></commit-hash> 就行。不是 merge，也不是 rebase，就是“把那个提交的内容，在当前分支上重演一次”，生成一个**新 commit**（哈希值不同，但改动内容一致）。
常见错误是：没切到目标分支就运行 cherry-pick，结果改到了源分支上；或者误挑了 merge commit（比如 Merge branch 'dev' into feature'），这类提交不能 cherry-pick，会报错或引入混乱历史。
- 先确认目标分支干净：
git status应显示 “nothing to commit, working tree clean” - 用
git log --oneline <source-branch></source-branch>查 commit 哈希，比如abcd123 - 切换过去：
git checkout target-branch（如dev或main） - 执行：
git cherry-pick abcd123
遇到冲突怎么处理
cherry-pick 冲突和 merge 冲突本质一样：Git 不知道该保留哪边的改动。但它不会自动暂停等你 resolve —— 它会卡在中间状态，等你手动干预。
典型现象是命令行停住、提示 “error: could not apply abcd123...”，同时 git status 显示 unmerged paths。
- 打开冲突文件，按标准方式编辑（找 >>>>>> 标记）
- 改完后
git add <file></file>标记为已解决 - 继续操作：
git cherry-pick --continue - 如果想放弃整个 cherry-pick：
git cherry-pick --abort（注意：这会丢掉所有已暂存的修改）
cherry-pick 和 merge 的关键区别在哪
不是“哪个更好”，而是“解决什么问题”。merge 是合并两个分支的全部分叉历史；cherry-pick 是复制某个 commit 的**补丁内容**，跟源分支无关。
这意味着：即使源分支后续被 reset、rebase 或删掉，你 cherry-pick 过来的 commit 依然有效。但反过来，它也**不继承原 commit 的父关系**——所以别指望靠它恢复分支拓扑。
- 想把 dev 分支里一个 bugfix 快速同步到 release/v2.1？用
cherry-pick - 想把 feature 分支整体合入 main，并保留完整提交链？用
git merge feature - 想把多个不连续 commit 一起搬过去？
git cherry-pick hash1 hash2 hash3，空格分隔 - 想搬一段连续区间（不含第一个）？
git cherry-pick start^..end
TortoiseGit 或 IDEA 里怎么操作
图形工具只是封装了命令行，逻辑完全一致，但界面容易让人忽略底层动作。
常见误区：在 source 分支右键选 “Cherry pick”，结果没提前切到 target 分支 —— 工具会默认在当前所在分支执行，很可能白忙活。
- TortoiseGit：必须先 右键 → Switch/Checkout 切到目标分支，再右键 source 分支日志里的 commit → “Cherry pick this commit”
- IDEA：在 Log tab 里 Ctrl+左键多选 commit → 右键 → “Cherry Pick” → 弹窗里确认目标分支（默认是当前分支，务必核对）
- 无论哪种工具，冲突弹窗出现后，都得手动点 “Accept Yours” / “Accept Theirs” 或进编辑器改，改完要点 “Commit” 才算真正完成
