基于其他未合并feature分支提交的PR显示冗余提交问题咨询

未合入的feat-a被feat-b依赖的最佳处理方案 #

仅在PR备注标注依赖不是最优方案，可根据场景选择以下更合理的处理方式：

• 确认feat-a一定会被合入，不会被驳回修改的场景：
  可以直接在feat-b的PR备注标注依赖 feat-a PR #对应编号，同时可以将feat-b PR的目标分支临时从develop改为feat-a，主流Git托管平台（GitHub/GitLab/Gitee等）均支持修改PR目标分支，修改后feat-b的PR只会展示自身的E、F提交，不会出现属于feat-a的C、D提交，避免审核人困惑。等feat-a正式合入develop后，再将feat-b的PR目标分支改回develop即可。
• 不确定feat-a是否会被合入，或者feat-a可能会有大量修改的场景：
  不要直接把整个feat-b rebase到feat-a上，改用git cherry-pick <修复提交的哈希值>命令，单独把你需要的那一个修复提交拣到feat-b分支即可。这样feat-b的提交链仍然基于原生develop，PR中不会携带多余提交。后续待feat-a正式合入develop后，再把feat-b rebase到最新的develop，Git会自动识别跳过重复的提交内容，不会产生冲突。

feat-a合入develop后，feat-b PR仍显示C、D提交的原因和处理方法 #

原因 #

90%以上的概率是feat-a合入develop时使用了压缩合入（Squash Merge）或变基合入（Rebase Merge），这两种合入策略都会生成全新的提交哈希，和feat-b分支上携带的C、D提交的原始哈希不一致。Git是通过提交哈希判断提交唯一性的，即使内容完全相同，哈希不同也会被判定为不同的提交，因此会在feat-b的PR中重复展示。如果feat-a使用的是普通合并提交（Create Merge Commit）的方式合入，Git可以识别到相同哈希的提交已经存在于develop，不会重复展示。

处理方法 #

只需要把feat-b分支rebase到最新的develop即可，操作命令如下：

# 切换到本地develop分支，拉取远端最新代码
git checkout develop
git pull origin develop
# 切换回feat-b分支执行rebase
git checkout feat-b
git rebase develop
# 操作过程中C、D提交和develop已合入内容完全一致，会被Git自动跳过
# 强推到远端feat-b分支刷新PR即可
git push origin feat-b --force

操作完成后刷新PR页面，C、D两个重复提交就会自动消失，仅保留feat-b自身的提交。

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