git cherry-pick 是什么
git cherry-pick 把其他分支上的指定提交复制到当前分支，生成一条内容相同但哈希不同的新提交。原提交的作者信息会保留，提交者则变成执行拣选的人。它常用于把某个修复同步到多个版本分支，而不必合并整条分支。
适用的边界
拣选适合单个或少量提交的移植，不适合当日常同步手段：大规模拣选会产生内容重复的提交，让两条分支之间的关系变得难以追踪。如果目标分支本就该整体跟进另一条分支，合并或变基才是正确做法。真要使用它，也应从依赖链中最早的那条开始按顺序拣选。
基本信息
| 适用平台 | Linux / macOS / Windows（Git 2.x） |
|---|---|
| 语法 | git cherry-pick <提交>… |
| 结果 | 内容相同、哈希不同；作者保留，提交者为执行者 |
| 常用参数 | -n 只应用不提交；-e 编辑信息；-x 附上原提交哈希 |
| 冲突处理 | 解决后 git add，再 git cherry-pick --continue |
| 中止方式 | git cherry-pick --abort |
典型使用场景
- 热修复同步：把主干上的修复复制到维护分支或旧版本分支
- 反向移植：把新版本的补丁搬回旧版本代码线
- 误分支补救：提交发在错误分支上，拣选到正确分支
- 选择性引入：只想要对方分支里的某一条改动
- 组合应用：用 -n 把多条拣选的改动攒起来合成一次提交
常用示例
常用示例
git switch release/2.x # 切到接收方分支
git cherry-pick 3f6a2b1 # 拣选单条提交
git cherry-pick -x 3f6a2b1 # 在提交信息里记录来源哈希
git cherry-pick -n 3f6a2b1 # 只应用改动，不自动提交
git cherry-pick A..B # 拣选一个连续区间
git cherry-pick --continue # 冲突解决后继续
git log --oneline -3 # 核对是否生成了新提交拣选时的常见状态
| 状态 | 含义 | 处理 |
|---|---|---|
| 新提交已生成 | 复制成功 | 用 log 核对内容 |
| CONFLICT | 目标分支上下文不匹配 | 解决后 add 再 continue |
| 空提交被跳过 | 改动已存在于目标分支 | 无需额外处理 |
| 提示 need to resolve | 仍有冲突文件未解决 | 用 status 逐个补齐 |
拣选会产生内容重复的提交。后续两条分支真正合并时，Git 通常能按内容识别并去重，但不要把拣选当日常同步手段。
依赖上下文的提交拣选到旧分支容易冲突，必要时沿着依赖链按顺序拣选，从最早的那一条开始。