Git Rebase引发重复代码审查？我的操作是否正确？

嘿，我来帮你捋清楚这个问题！首先得纠正你描述里的一个小错误：当你在feature分支执行git rebase development后，feature分支的提交结构不会停留在原来的C。正确的rebase会把你的feature提交（C）重新应用到development的最新提交（D）顶端，生成一个内容相同但哈希值不同的新提交C'，最终分支结构应该是这样的：

development: A → B → D
feature:      A → B → D → C'

那为什么你会看到PR里把已经审查过的D当成新变更，甚至出现两个D提交呢？大概率是你执行rebase前没同步本地的development分支，这才是问题的核心。

正确的Rebase流程应该是这样的： #

• 第一步，先确保本地的development分支是远程最新版本（也就是包含提交D）：

  git checkout development
  git pull
  

• 第二步，切回feature分支执行rebase：

  git checkout feature
  git rebase development
  

• 如果过程中遇到冲突，解决完冲突后执行git rebase --continue，直到rebase完成。

你之前操作的问题所在： #

如果你跳过了第一步，直接在本地development还停留在A--B的状态下执行rebase，这个操作其实不会有任何效果——因为你的feature本来就基于本地development的最新提交（B），rebase找不到需要移动的提交。

之后你把feature推到远程，再创建PR到已经更新到A--B--D的远程development时，Git会对比两个分支的最新提交（C和D），显示它们相对于共同祖先B的所有差异——也就是D的变更加上C的变更。这就会让你误以为D是feature里的新提交，但实际上这只是两个分支“分叉”导致的差异显示，并不是真的有两个D提交。

现在怎么修复？ #

按下面的步骤操作就能解决：

1. 同步本地development到最新：git checkout development && git pull
2. 回到feature分支重新执行rebase：git checkout feature && git rebase development
3. 解决可能出现的冲突，完成rebase
4. 因为rebase生成了新的提交C'，需要强制推送到远程feature分支：git push origin feature --force（⚠️ 注意：如果有其他同事在这个feature分支上工作，一定要先和他们沟通，强制推送会覆盖远程分支的现有内容）

完成这些后，你的feature分支就完全基于最新的development了，此时创建PR只会显示你原本要合并的C'的变更，不会再出现已经审查过的D的内容。

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