Git合并功能分支时如何处理还原提交

当feature-b临时合并到feature-a又被git revert -m1撤销，随后feature-a合并到master时，GitHub会因为feature-b的提交存在于master历史中，误关feature-b的PR，但实际上feature-b的代码并未真正合并到master。以下是具体解决方法：

方案一：新建分支迁移变更（推荐，无历史改写风险） #

• 切换到本地master并拉取最新代码：

  git checkout master
  git pull origin master
  

• 基于master创建新分支（例如feature-b-revised）：

  git checkout -b feature-b-revised master
  

• 迁移原feature-b的代码变更：
  • 若原feature-b提交线性清晰，用cherry-pick批量迁移提交：

    git cherry-pick <原feature-b起始提交SHA>..<原feature-b末尾提交SHA>
    

  • 若提交历史复杂，直接生成并应用差异补丁：

    git diff master feature-b > feature-b.patch
    git apply feature-b.patch
    

• 解决冲突后提交变更，推送到远程：

  git add .
  git commit -m "重新提交feature-b的功能变更"
  git push origin feature-b-revised
  

• 关闭原feature-b的PR，基于新分支创建新PR，GitHub会正常识别未合并的变更。

方案二：改写原feature-b的提交历史（需团队配合） #

此方法会修改远程分支的历史，需确保团队成员同步操作，避免冲突：

• 切换到原feature-b分支：

  git checkout feature-b
  

• 基于最新master变基，生成新的提交SHA：

  git rebase --onto master <feature-b从master分出时的提交SHA>
  

• 解决变基冲突后，强制推送覆盖远程分支：

  git push origin feature-b --force
  

• 回到原PR页面，GitHub会更新提交记录并重新激活PR（若已关闭，可手动重新打开）。

后续预防建议 #

• 尽量避免临时合并完整功能分支到开发分支，如需测试依赖，优先用git cherry-pick单个提交或创建临时测试分支。
• 执行合并撤销操作后，记录相关提交SHA，后续分支合并时明确被撤销的提交范围，避免平台误判。

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