Git分支未基于最新版本变基就推送，PR含已合并提交该如何解决？

一、是否会产生问题？能否直接合并？ #

• 首先要确认working-feature的合并状态：
  • 如果working-feature尚未合并到develop：绝对不能直接合并，会把还在评审中的未验收代码提前合入develop
  • 如果working-feature已经完全合入develop：
    • 直接合并理论上不会产生代码冲突也不会污染develop代码，这些重复提交的内容和develop上的对应提交内容完全一致
    • 存在两个明显弊端：PR提交历史冗余混乱，后续排查问题回溯提交记录时会产生不必要的干扰；如果团队要求提交历史线性干净，这种PR不符合规范无法直接合并
• 结论：仅在团队无严格提交历史规范、且working-feature已合入develop的前提下可以直接合并，其余情况建议清理冗余提交后再合并。

二、移除已合并冗余提交的操作方法 #

操作前建议先备份本地new-feature分支代码，避免操作失误丢失自有提交

方法1：交互式变基清理（最常用，适合new-feature自有提交数较多的场景） #

1. 拉取本地develop分支的最新远端代码：
   git checkout develop && git pull origin develop
2. 切换回new-feature分支启动交互式变基：
   git checkout new-feature && git rebase -i develop
3. 在弹出的变基编辑界面中，将所有属于working-feature的冗余提交前的pick修改为drop，仅保留new-feature本身的提交记录，保存退出后变基将自动执行
4. 本地验证代码无误后，强制推送覆盖远端new-feature分支：
   git push origin new-feature -f

强制推送完成后，远端已提交的PR会自动同步更新，冗余提交会直接消失，无需重新提交PR

方法2：Cherry-Pick 转移提交（适合new-feature自有提交数较少的场景） #

1. 拉取最新develop代码后，从develop切换出一个新的临时分支：
   git checkout develop && git checkout -b temp-new-feature
2. 复制new-feature上所有自有提交的哈希值，逐个cherry-pick到临时分支：
   git cherry-pick <提交哈希1> <提交哈希2>
3. 验证临时分支代码无误后，删除本地旧new-feature分支，将临时分支重命名为new-feature后强制推送：
   git branch -D new-feature && git branch -m new-feature && git push origin new-feature -f

注意：如果new-feature分支有多人同时协作开发，强制推送前需要同步所有协作者，避免其他人本地代码和远端产生冲突。

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