如何将release分支的指定修复迁移至master分支？兼询合并风险

嘿，这个场景我在日常开发里碰到过好多次，咱们一步步拆解来解决：

第一步：把指定提交迁移到master分支 #

首先确保你的工作区是干净的（没有未提交的更改），然后切换到master分支：

git checkout master

接下来一定要按提交的先后顺序执行cherry-pick（因为G依赖F，J依赖G，顺序错了可能会出问题）：

# 替换成实际的提交哈希，比如F的哈希是a1b2c3，G是d4e5f6，J是g7h8i9
git cherry-pick <F的提交哈希>
git cherry-pick <G的提交哈希>
git cherry-pick <J的提交哈希>

如果过程中遇到冲突，Git会暂停cherry-pick流程。这时候你需要手动修改文件里的冲突标记，解决完后执行：

git add <冲突的文件>
git cherry-pick --continue

要是你想跳过当前提交就用git cherry-pick --skip，彻底放弃整个cherry-pick流程就用git cherry-pick --abort。

完成后，master分支就会变成 A--B--C--F'--G'--J'（这里的F'、G'、J'是新生成的提交，哈希和release里的不一样，但内容完全一致）。

第二步：后续合并release到master的风险说明 #

你担心的合并问题，其实Git的合并逻辑是基于内容而非提交哈希的，所以大部分情况下不会有问题：

• 等你之后要把release合并到master时，执行git checkout master && git merge release，Git会自动对比两个分支的内容，发现F、G、J的更改已经存在于master中，会直接忽略这些重复内容，只合并release里独有的提交（D、E、H、I、K）。
• 唯一的例外情况：如果在cherry-pick之后，你在master上修改了F、G、J涉及的代码，同时release分支上的后续提交（比如H、I）也修改了同样的代码，那合并时会触发冲突。不过这属于正常的合并冲突场景，和普通分支合并的冲突处理方式一致，手动解决即可。

额外小技巧 #

为了让后续追踪和合并更顺畅，你可以：

• 执行cherry-pick时加上-x参数，比如git cherry-pick -x <提交哈希>，这样Git会在新提交的备注里自动加上(cherry picked from commit XXX)，方便你后续知道这个提交的来源，也能帮助Git更准确地识别重复内容。
• 尽量避免在master上随意修改cherry-pick过来的代码（除非是必须的适配调整），保持和release分支上对应提交的内容一致，能大幅降低后续合并的冲突概率。

内容的提问来源于stack exchange，提问作者MorayM