git cherry-pick 教程

一句话理解

git cherry-pick 会把指定提交引入的改动，重新应用到当前分支上。

它最适合什么场景

• 把某个修复补丁从一个分支带到另一个分支
• 只需要某几个提交，而不是整条分支历史
• 发布分支需要精确挑选变更时

基本用法

git checkout release/1.2
git cherry-pick <commit-hash>

这会在当前分支上创建一个新的提交，内容来自被挑选的提交，但提交 ID 会不同。

一次挑多个提交

git cherry-pick <commit-a> <commit-b>

如果这些提交存在依赖关系，建议按照原始顺序挑选。

典型使用场景

场景 1：把线上修复带回发布分支

主分支上已经修了一个 bug，但你不想把整条开发历史合并到发布分支时，cherry-pick 很适合做补丁回带。

场景 2：从实验分支中选中一个成熟提交

如果实验分支里只有一部分提交值得保留，直接 merge 往往太重，这时 cherry-pick 更精确。

冲突时怎么处理

git status
# 解决冲突
git add <resolved-files>
git cherry-pick --continue

放弃当前操作：

git cherry-pick --abort

它和 merge / rebase 的区别

• merge：整合一段分支历史
• rebase：重写一组提交的基底
• cherry-pick：只拿某个或某几个提交的内容

所以 cherry-pick 更像“精确搬运改动”，而不是“整合整条历史线”。

使用前要注意什么

• 先确认目标提交是否依赖别的前置提交
• 先确认当前分支是否已经包含同类改动
• 先确认你是不是应该整合整条分支，而不是单挑提交

常见误区

误区 1：cherry-pick 完全等于复制提交

不对。它复制的是改动效果，不是原始提交对象本身。

误区 2：cherry-pick 越多越灵活

过度使用会让不同分支之间出现重复但不完全相同的提交，后续排查历史时会更复杂。

实践建议

如果一个功能需要长期存在于多个分支，优先考虑更稳定的分支策略；cherry-pick 更适合补丁级、精选式迁移。

这条命令在流程里解决什么问题

git cherry-pick 直接影响历史表达、引用位置或提交之间的关系。读这类命令时，要先判断这次操作是在整理本地未共享历史，还是在处理已经公开给团队的历史。

典型用例

• 在合并、回滚、挑提交或整理提交序列时，用 git cherry-pick 重塑历史表达。
• 把 git cherry-pick 放进“先备份、再变更、最后复核”的高风险操作流程，降低误操作损失。
• 在复盘冲突、回滚事故或判断分支关系时，用 git cherry-pick 理清提交之间的因果链。

图例理解

特殊情况与边界

• 历史类命令最常见的风险，是对已经共享出去的提交继续做重写或移动。
• 如果这次操作可能影响团队协作，先跑 git status、git log --oneline --graph 和 git reflog，再决定是否继续。
• 一旦不确定，就先建一个备份分支，让自己保留“能回去”的选项。

跟着做一遍

git switch -c release/1.2
# 另开一个 feature 分支做一条修复提交

继续学习建议

后续建议配合阅读：

1. git merge
2. git rebase
3. git reset