git cherry-pick 是最直接的办法，它不拉整个分支历史，只复制指定提交的变更内容并生成新提交；务必用具体 SHA（如 abc1234），不可直接 cherry-pick 分支名，否则易报错或静默失败。
git cherry-pick 选中单个提交合并
想把某个分支上已提交但还没合入的改动，单独拎出来塞进当前分支？git cherry-pick 是最直接的办法。它不拉整个分支历史，只复制指定提交的变更内容，生成一个新提交。
常见错误是直接 git cherry-pick branch-name —— 这会尝试 pick 分支顶端提交，但若该提交已在当前分支存在（哪怕 SHA 不同），Git 会报 The commit ... is a merge but no -m option was given 或静默失败。务必用具体 SHA。
- 先查目标提交：在源分支运行
git log --oneline -n 5，记下要 pick 的abc1234（前7位即可） - 切到目标分支：
git checkout target-branch - 执行：
git cherry-pick abc1234；若冲突，解决后git add . && git cherry-pick --continue - 注意：
cherry-pick生成的新提交 SHA 与原提交不同，后续不可用git revert原 SHA 回退
合并多个非连续提交时怎么避免顺序错乱
要挑三个散落在不同位置的提交（比如 a1b2c3d、e4f5g6h、i7j8k9l），不能一股脑全丢进命令——Git 会按你输入顺序应用，但若后一个提交依赖前一个的修改（比如改了同一行代码），顺序错就必然冲突。
正确做法是还原原始提交时间线：用 git log source-branch --oneline --reverse 找出它们在源分支的实际先后顺序，再按此顺序执行 cherry-pick。
- 推荐一次性写全：
git cherry-pick a1b2c3d e4f5g6h i7j8k9l（前提是顺序已确认） - 若中途出错，
git cherry-pick --abort可退出，不会污染工作区 - 不要用
-x参数自动加“cherry picked from…”备注——团队若用 squash 合并策略，CI 可能因重复 commit message 拒绝构建
遇到 “detached HEAD” 状态别慌
执行 git cherry-pick 时如果当前不在任何本地分支（比如刚 git checkout abc1234），Git 会进入 detached HEAD 状态，此时 commit 无法被分支引用，一不留神就丢失。
- 检查是否 detached：
git status显示 “HEAD detached at abc1234” 就是 - 立刻创建临时分支保存结果：
git checkout -b temp-fix-branch，再 push 或合并 - 更稳妥的做法：始终先
git checkout target-branch再操作，避免意外脱离分支上下文
cherry-pick 后如何验证改动没漏没多
肉眼比对容易漏掉空格、换行或配置项注释——尤其当原提交含大量格式调整时。靠 git show 和 git diff 组合验证更可靠。
- 看 cherry-pick 新提交改了啥：
git show HEAD - 对比原提交和新提交的 patch 是否一致：
git diff abc1234 HEAD（应为空输出） - 若发现差异，说明 cherry-pick 过程中手动改过冲突解决结果，需重新评估是否引入了意料外变更
真正麻烦的是跨大版本合并：比如从 v2.3 分支 pick 一个修复，合入 v3.0 分支时，函数签名或依赖路径可能已变，cherry-pick 成功不代表逻辑仍正确，必须跑对应测试用例。
