你的核心困境在于：直接将feature-1变基到master会产生大量冲突（且你不确定如何解决），但将master变基到feature-1冲突少，却会打乱feature-2的后续变基流程。其实我们可以通过调整feature-2的变基目标，来规避这个问题，同时不用硬着头皮处理feature-1到master的大量冲突。

推荐方案：变基master到feature-1，再修正feature-2的基准 #

这个方案的思路是：先利用冲突少的master→feature-1变基得到正确的代码状态，再将feature-2的提交重新锚定到新master的对应节点上，这样后续feature-2的变基就不会出现合并基准跳转到A的问题。

步骤详解： #

1. 备份当前分支（重要！）
   先备份master和feature-2，防止操作失误无法回滚：

   git checkout master
   git branch master-original
   git checkout feature-2
   git branch feature-2-original
   

2. 将master变基到feature-1
   执行这个操作，你只需要解决少量冲突（你提到的相对简单的冲突）：

   git checkout master
   git rebase feature-1
   

   完成后，master的提交历史会变成：

   A---B---C---E---F---...---G---D'
   

   这里的D'是原master中提交D在feature-1顶端G上应用后的版本，代码状态和你期望的「D加上feature-1所有修改」完全一致，只是提交顺序反过来了。

3. 修正feature-2的变基基准
   现在需要把feature-2的提交（H-I-J-K）从原master的D节点，移到新master的D'节点上。首先找到原master中D提交的哈希值（可以用git log master-original查看），假设哈希是d123456，然后执行：

   git checkout feature-2
   git rebase --onto master d123456 feature-2
   

   这个命令的含义是：把feature-2中从d123456（原D提交）之后开始的所有提交，重新应用到当前master的顶端（也就是D'）。

   完成后，feature-2的历史会变成：

   A---B---C---E---F---...---G---D'---H'---I'---J'---K'
   

   此时，feature-2和新master的合并基准就是D'，后续再对feature-2进行变基或合并操作时，完全不会出现基准跳转到A的问题，流程和之前一样顺畅。

关于你期望的历史顺序：为什么很难实现 #

你期望master的历史是A---B---C---D---E'---F'---...---Z'，但这个需求本质上就是将feature-1的所有提交变基到master的D之后——这和你一开始想避免的「feature-1到master的大规模变基」是完全一样的操作，必然会面临大量冲突。

无论用什么技巧（比如cherry-pick批量提交、rebase --onto），只要是把feature-1的60个提交放到D之后，都需要解决这些冲突，没有绕不开的捷径。因为Git需要逐个处理feature-1提交与D提交之间的代码差异，这正是冲突的来源。

总结 #

如果你能接受master的提交顺序是「feature-1提交在前，D'在后」（代码状态完全符合你的需求），那么推荐的方案可以帮你避免大量冲突，同时保证feature-2的后续流程正常。如果必须严格按照你期望的历史顺序来，那确实只能硬着头皮执行feature-1到master的变基，或者和feature-1的负责人沟通，看对方是否能协助解决冲突。

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