Cherry Pick提交h到main时，如何避免引入分支历史引发合并冲突？

你的核心需求是提取提交h相对于f的纯净变更，而非带上feature1分支（e、f）的历史，以下是两种可靠的实现方式：

方法一：生成纯净补丁并手动应用 #

这种方式直接提取h在f基础上的所有变更，避免Git自动引入分支差异：

1. 切换到main分支：

   git checkout main
   

2. 生成仅包含h相对于f的补丁文件：

   git diff f h > h-only.patch
   

   （这里的f是feature1分支的最后一个提交ID，也可以直接用分支名feature1，因为f是feature1的顶端）
3. 将补丁应用到main分支：

   git apply h-only.patch
   

4. 若出现冲突，Git会生成.rej后缀的冲突文件：
   • 打开冲突的原文件，手动合并内容（只保留h的变更即可）
   • 删除对应的.rej文件
   • 执行git add <冲突文件名>标记冲突已解决
5. 提交最终变更：

   git commit -m "Apply changes from feature2's commit h"
   

方法二：用变基剥离feature1历史，直接迁移h到main #

这种方式通过Git变基，把h从feature1的分支上“搬”到main分支顶端：

1. 切换到feature2分支：

   git checkout feature2
   

2. 执行变基命令，仅迁移f之后的提交（也就是h）到main上：

   git rebase --onto main f feature2
   

   这个命令的逻辑是：把feature2分支中，f提交之后的所有提交（这里只有h），重新应用到main分支的最新提交（d）上
3. 若变基过程中出现冲突：
   • 手动修改冲突文件，保留h的变更
   • 执行git add <冲突文件名>
   • 继续变基：

     git rebase --continue
     

4. 变基完成后，feature2分支的历史就变成d -> h'（h'是h的变更适配到main后的新提交），此时切换回main并合并：

   git checkout main
   git merge feature2
   

   因为是线性历史，Git会自动执行快进合并，不会产生额外的合并提交

为什么之前的操作会冲突？ #

直接cherry-pick h时，Git会计算h与它的父提交f的差异，然后尝试把这个差异应用到main的d上。但f本身是基于feature1的e提交，和main的d之间存在e、f以及main的c、d的代码差异，这些差异就导致了合并冲突。而上面的两种方法都只提取了h在f上的增量变更，完全避开了feature1分支的历史内容。

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