cherry-pick怎么用

多分支开发中非常典型的「bug修复同步到多个分支」场景，有两种主流解决方案：

---

✅ 方案一：cherry-pick（推荐！只同步bug修复提交，最干净）

适用场景

只需要把「修复bug的那1个（或几个）提交」同步到dev分支，不需要把master的其他代码也带过来（比如master还有其他和dev无关的改动，不想引入）。

操作步骤

1. 先找到bug修复的提交哈希

在master分支找到你刚才修复bug的那个提交的哈希值：

# 查看master的提交历史，找到修复101bug的那一条，复制前面的短哈希（比如a1b2c3d）
git log --oneline master

输出示例：

a1b2c3d (HEAD -> master) fix: 修复101号bug
e4f5g6h 其他提交
h7i8j9k 更早的提交

2. 切换到dev分支，执行cherry-pick

# 1. 切到dev分支，拉取最新代码
git switch dev
git pull origin dev

# 2. 把master上的bug修复提交，复制到dev分支
git cherry-pick a1b2c3d

3. 解决冲突（如果有）

如果cherry-pick出现冲突：

1. 手动修改冲突文件
2. 标记冲突解决：git add 冲突文件名
3. 继续完成cherry-pick：git cherry-pick --continue
4. 想放弃的话：git cherry-pick --abort

4. 推送dev分支

git push origin dev

✅ 效果：dev分支上会新增一个和master上完全一样的bug修复提交，不会引入master的其他代码，提交历史非常干净。

---

👉 cherry-pick 进阶

如果bug修复是连续的多个提交，可以批量cherry-pick：

# 批量复制从 提交1 到 提交2 的所有提交（左开右闭，包含结束提交）
git cherry-pick 开始提交哈希^..结束提交哈希

---

✅ 方案二：合并master到dev（同步所有master更新）

适用场景

dev分支需要同步master的所有最新改动（除了bug修复，master还有其他需要同步到dev的更新），不介意产生合并提交。

操作步骤

# 1. 切到dev分支，拉取最新代码
git switch dev
git pull origin dev

# 2. 把master的所有最新代码合并到dev
git merge master

# 3. 如果有冲突，手动解决后完成合并
git add 冲突文件
git commit -m "merge: 合并master最新代码，同步101bug修复"

# 4. 推送dev分支
git push origin dev

✅ 效果：dev分支会同步master的所有最新提交，包括bug修复，会生成一条合并提交，提交历史会记录这次合并。

---

📌 两种方案对比&选择建议

方案	优点	缺点	适用场景
cherry-pick	干净，只同步需要的提交，不引入多余代码	多个提交需要逐个操作，适合少量提交	✅ 只同步bug修复，不需要master其他代码
merge master	一次同步所有更新，操作简单	会引入master所有代码，可能带无关改动	✅ dev需要和master保持完全同步，所有更新都要

---

⚠️ 注意事项

1. 绝对不要反过来把dev合并到master！dev是开发分支，有未完成的代码，合并到master会把未上线的代码带到线上。
2. cherry-pick 是复制提交，不是移动：master上的原提交还在，dev上会生成一个内容相同、哈希不同的新提交，这是正常的。
3. 不要cherry-pick合并提交，会导致提交历史混乱。
4. 如果有多个版本分支（比如v1.0、v2.0线上分支）都有这个bug，都可以用cherry-pick把修复提交同步到所有分支，这是cherry-pick最核心的使用场景！