Git协作中Pull Request后出现重复提交，如何解决？

问题原因 #

你遇到的重复提交（含一个带verified标签的记录），大概率是以下两种情况导致：

• 合并方式引发的提交重复：管理员合并PR时如果选择了「Squash and merge」，会把你navbar分支的提交压缩成一个新的提交合并到main分支，而你本地仓库里还保留着原分支的旧提交。如果之后你没及时清理本地分支，又把旧分支的提交合并到本地main再推送，就会出现两条提交信息完全一致的记录（带verified的是管理员生成的新提交，另一个是你本地的原提交）。
• 本地分支未同步最新代码：PR合并后，你没有先拉取远程main的最新代码到本地，就直接操作本地分支，导致旧提交被再次引入到main分支的历史中。

另外，带verified标签的提交是因为使用了GPG/SSH签名（可能是管理员的签名），另一个未验证的是你本地提交时未签名，两者只是签名状态不同，但提交内容/信息一致，所以看起来是重复记录。

紧急修复步骤 #

如果已经出现重复提交，按以下步骤清理本地历史并同步远程：

1. 切换到main分支：git checkout main
2. 重置本地main分支到远程最新状态（会丢弃本地未提交的变更，执行前确认）：git reset --hard origin/main
3. 强制推送本地main到远程（仅在团队确认无其他人同时修改main时执行）：git push origin main --force

规范操作流程避免重复提交 #

既然你们有原仓库的推送权限，当前的直接克隆开发方式是可行的，只需调整流程：

• 开发新功能前，先同步远程main的最新代码：

  git checkout main && git pull --rebase
  

• 基于最新的main创建功能分支：

  git checkout -b navbar
  

• 开发期间定期同步main分支代码到功能分支（避免后续合并冲突）：

  git checkout navbar && git pull --rebase origin main
  

• 提交并推送功能分支后，创建PR等待合并
• PR合并完成后，立即同步main并删除本地功能分支：

  git checkout main && git pull --rebase && git branch -d navbar
  

更优的项目贡献方式 #

方式1：优化直接克隆开发的合并策略 #

建议团队统一PR合并方式：

• Rebase and merge：将功能分支的提交放到main分支顶部，保持线性提交历史，不会生成多余的merge commit，也能避免重复提交（前提是本地及时同步）。
• Squash and merge：把功能分支的所有提交压缩成一个新提交合并到main，适合小功能或bug修复，历史更整洁，但必须注意PR合并后立即删除本地功能分支，避免旧提交被再次推送。

方式2：优化Fork仓库的同步流程 #

如果之前用Fork的方式觉得同步麻烦，可以用以下流程解决：

1. 克隆自己的Fork仓库到本地后，添加原仓库为upstream远程：

   git remote add upstream original-repo.git
   

2. 每次开发新功能前，同步原仓库的main分支到本地main：

   git checkout main && git fetch upstream && git rebase upstream/main
   

3. 基于本地main创建功能分支，开发完成后推送到自己的Fork仓库，再创建PR到原仓库。
   这种方式不会影响原仓库的历史，适合多人协作的场景，且同步操作只需执行上述两行命令即可，并不繁琐。

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