跳到主要内容

Git Cherry-pick 移植提交

主线修了个 bug，需要同步到维护分支；或者某个功能分支上只有一条提交值得要。这类"只搬一部分提交"的需求，cherry-pick 就是标准答案。

一、基本用法​

git switch release-1.x
git cherry-pick 9c8d7e6

它会取出那个提交的 diff，在当前分支重放一次，生成一个新的 commit（新 hash）。

二、批量挑​

git cherry-pick A..B          # 从 A 之后到 B（不含 A）
git cherry-pick A^..B         # 含 A
git cherry-pick A B C         # 任意几条

顺序按你写的顺序来，不是按时间。

三、冲突处理​

冲突后 Git 会停下来：

# 手工解决冲突标记后
git add .
git cherry-pick --continue

git cherry-pick --abort       # 整个放弃，回到操作前
git cherry-pick --skip        # 跳过这条，继续下一条

批量 cherry-pick 中途冲突，--abort 会把已完成的也一起回滚。

四、保留原作者​

默认 pick 出来的提交，作者还是原提交的作者，committer 变成你。想显式带上：

git cherry-pick -x 9c8d7e6     # 在 message 里追加 "(cherry picked from commit ...)"

-x 在长期维护分支上很有用——以后查某行代码是从哪来的，一眼能追到主线提交。

五、只搬不提交​

git cherry-pick -n 9c8d7e6     # 改动进暂存区，不生成 commit

适合把几条提交拼成一个再提交。

六、和 merge / rebase 怎么选​

需求用什么
整条分支的工作都要merge 或 rebase
只要其中几条提交cherry-pick
提交之间互相依赖别用 cherry-pick，改 merge / rebase
主线 → 维护分支的热修复cherry-pick -x

七、坑点清单​

  • 新 hash 不同，同步一次之后两边历史就不一样了，下次别再整分支 merge 过来，否则重复提交
  • 依赖链条断裂：单独 pick 中间一条，很可能因为缺少前一条的改动而冲突
  • merge commit 不能直接 pick，要加 -m 1 指定主线父提交
  • 空提交：改动已经在当前分支存在，pick 会因无内容而失败（加 --allow-empty 可放行）

八、典型工作流​

git log --oneline main | head -20        # 在主线找要搬的提交
git switch release-1.x
git cherry-pick -x a1b2c3 d4e5f6        # 搬两条修复
git push

搬完回头在主线提交上留个评论或标签（git notes add 之类），说明已同步到维护分支，是很省事的好习惯。