如何使用Rebase移除已合并的Feature Branch？

你明确接受历史重写的前提下，优先用带合并保留能力的交互式rebase，这是目前最贴合需求的方案，不会出现历史扁平化，也不需要手动梳理特性分支的所有提交。

首选方案：git rebase -r 交互式重写（保留所有原有合并结构） #

注意：旧版Git的--preserve-merges参数已被官方废弃，存在大量合并拓扑处理bug，不要使用，Git 2.22及以上版本提供的--rebase-merges（简写-r）才是正确的保留合并结构的参数
操作步骤：

1. 切到目标分支并同步最新代码：

   git checkout develop
   git pull
   

2. 定位需要移除的目标合并提交哈希（即你提到的棕色标注的「Merge pull request #8661」提交），记为<bad_merge_hash>。
3. 取该合并提交的第一父提交，也就是合并发生前develop分支所在的提交点，记为<base_hash>：

   git rev-parse <bad_merge_hash>^1
   

4. 启动带合并保留的交互式rebase，重放范围是<base_hash>之后到当前分支顶端的所有提交：

   git rebase -i -r <base_hash>
   

5. 编辑器弹出的待操作列表里，Git会自动按原有拓扑标注所有普通提交（pick前缀）和合并提交（merge前缀），你只需要找到对应目标合并的整个指令块，直接删除这几行即可，其余所有指令保持原样不要修改。
6. 保存退出编辑器，Git会自动按原有结构重放剩下的所有提交、合并操作。过程中如果遇到冲突，按正常流程解决后执行git add <冲突文件路径>，再执行git rebase --continue即可，直到rebase流程走完。

这个操作的最终效果：目标合并引入的所有特性提交、合并记录会被完全从提交历史中移除，其余所有合并提交的拓扑结构完全保留，不会出现历史扁平化问题，后续需要重新合入该特性时，直接正常走PR合并流程即可，不会出现git revert带来的祖先提交识别阻碍。

次选方案：git rebase --onto（仅适用于目标合并后无其他合并提交的场景） #

如果你确认目标合并之后的提交都是线性提交、没有其他合并记录，可以用onto指令快速跳过目标合并，操作更简单：

1. 同样先定位<bad_merge_hash>和它的第一父提交<base_hash>
2. 执行rebase指令：

   git rebase --onto <base_hash> <bad_merge_hash> develop
   

3. 解决可能出现的冲突后完成流程即可。
   该方案的缺陷是不会保留目标合并点之后的其他合并拓扑，会把后续的合并提交全部扁平化，非特殊场景不推荐使用。

不推荐方案说明 #

• 普通git revert -m 1 <bad_merge_hash>：正如你提到的，该操作只是生成一个反向提交抵消特性的代码变更，原有特性提交会全部保留在历史中，后续重新合入特性时，Git会判定特性分支的提交已经是当前分支的祖先，不会重新合入对应变更，必须额外执行一次revert the revert的操作才能恢复，流程容易出错，还会在历史中留下多余的revert记录。
• 手动梳理特性分支所有提交再批量drop：完全不需要做这个重复工作，-r模式下的交互式rebase会自动识别被删除的合并提交关联的所有特性提交，不需要你手动逐个查找提交哈希，哪怕是大型仓库也不会增加额外操作成本。

操作后注意事项 #

• 重写历史后推送远端时，使用git push --force-with-lease，不要用裸--force：前者会在检测到远端有其他人推送的新提交时自动拒绝推送，避免覆盖团队成员的提交。
• 推送完成后同步通知所有团队成员，本地develop分支执行git fetch && git reset --hard origin/develop同步最新历史，不要直接执行git pull，否则会把旧的历史重新合并进来产生冗余的合并提交。

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