git cherry-pick 是生产热修复的唯一合理选择，因为它仅提取指定提交的变更diff并重放为新提交，避免merge引入未测试代码、接口变更或重构，保障原子性、可追溯性与ci/cd稳定性。

紧急 Bug 修复必须用 git cherry-pick，而不是 git merge —— 否则极大概率把未测试代码、接口变更甚至破坏性重构一起推上生产环境。

为什么 git cherry-pick 是生产热修复的唯一合理选择

当你在 dev 或 feature 分支上修好一个线上支付金额计算错误，那个修复只存在于一次提交里（比如 a1b2c3d），而该分支其余几百次提交全是下周才上线的功能。此时 git merge dev 等于把整条开发流水线“倒灌”进生产分支，风险不可控。

而 git cherry-pick a1b2c3d 只提取这次修改的 diff，生成一个新提交（哈希值不同），不带任何历史依赖。它不是“复制提交”，是“重放变更”——这才是生产环境需要的原子性操作。

• 它不会改变目标分支的原有提交图谱，main 分支仍保持干净、可追溯
• CI/CD 流水线能照常运行，因为只是新增一个普通提交，不是合并引入大量新文件或删除
• 审计时可清晰看到：这个补丁来自哪个原始分支、哪个开发者、哪次修复

git cherry-pick 命令执行前必须做的三件事

跳过这三步，90% 的 cherry-pick 会在生产环境引发二次故障。

Cnb Cool Git

CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。

下载

• 确认目标提交是否“自包含”：运行 git show a1b2c3d，检查是否只改了 1–2 个文件、没调用未提交的新工具函数、没依赖其他未 pick 的配置项
• 检查目标分支是否已存在相同逻辑：比如你准备 pick 一个 JWT token 校验修复，先 git grep -n "verifyToken" main，避免重复实现或签名方式冲突
• 在预发布分支（如 staging）上先试跑：不要直连 main，先 git checkout staging && git cherry-pick a1b2c3d，跑通集成测试再推进生产

遇到冲突时别硬 --continue，先做这三步判断

冲突不是操作失败，而是 Git 在提醒：“这段代码在目标分支上已经不一样了”。常见报错像：

Auto-merging src/payment/calculator.js
CONFLICT (content): Merge conflict in src/payment/calculator.js

这时直接 git add . && git cherry-pick --continue 很危险。

• 先 git diff 看冲突块：确认是同一行被两边修改（真冲突），还是只是空行/注释差异（可安全接受 ours）
• 查 git log -p -n 3 main -- src/payment/calculator.js：看 main 分支最近对该文件的改动，判断当前冲突是否源于已有热修复覆盖
• 如果冲突涉及核心算法（比如金额四舍五入逻辑），必须人工比对两版实现，不能靠编辑器自动合并 —— 曾有团队因忽略这点，导致 cherry-pick 后精度从 2 位变成 0 位

GitLab Web 界面 cherry-pick 的隐藏限制与绕过方式

GitLab UI 上点 “Cherry-pick” 按钮很便捷，但它默认只允许 pick 到**同项目内已存在的分支**，且不支持 -n 或 -x 参数。

• 如果你要 pick 到一个还没创建的 release 分支（比如 release/v2.1.5），得先 git checkout -b release/v2.1.5 main 创建空分支，再用 CLI 执行：git cherry-pick -x a1b2c3d
• UI 不显示 commit 的 parent hash，无法判断是否为合并提交（merge commit）。而 git cherry-pick 默认拒绝 merge commit —— 需加 -m 1 指定主父提交，否则报错：fatal: Mainline was specified but commit ... is not a merge.
• GitLab MR 页面里 cherry-pick 生成的提交，作者信息会变成触发操作的用户，而非原始提交者。如需保留署名，必须用 CLI + --no-commit + 手动 git commit --author="..."

真正容易被忽略的点是：cherry-pick 后的提交，虽然内容一致，但测试覆盖率可能下降——因为原始提交的单元测试可能没被一起 pick，或者测试 mock 方式在目标分支已失效。每次 cherry-pick 完，务必手动验证对应路径的测试是否真实通过，而不是只看 CI 状态绿了。