如何同步Fork的开源仓库以创建仅含目标修改的干净拉取请求

冗余提交的核心成因 #

之前出现PR混入同步提交的问题，本质是bug修复分支的提交链路中，夹入了所有不属于单次修复的同步操作提交——不管是通过PR同步到个人Fork产生的合并提交，还是本地直接合并上游产生的合并提交，只要这些提交被纳入了bug修复的分支历史，在向上游发起PR时，Git就会自动把分支上和上游主分支有差异的所有提交全部纳入对比范围，最终导致PR内容冗余。

标准化操作流程 #

• 第一步：配置好本地仓库的远端映射
  在本地仓库根目录执行git remote -v确认远端配置：
  • origin 对应你在GitHub上维护的个人Fork仓库地址
  • upstream 对应项目上游官方原仓库地址
    如果缺少upstream配置，执行git remote add upstream <上游原仓库的Git地址>完成绑定
• 第二步：每次做bug修复前，从最新的上游主分支切独立工作分支
  这是避免冗余的核心操作，且不需要你平时刻意维护个人Fork主分支的同步状态，刚好适配零散、低频率的bug修复贡献场景：
  • 先拉取上游仓库的全量最新提交：执行git fetch upstream
  • 不要直接在个人Fork的主分支、或者历史遗留的旧工作分支上改代码，直接基于上游最新的主分支创建专属本次bug修复的工作分支：
    git checkout -b fix/[具体bug描述] upstream/main
    （如果上游主分支为master则将命令中的main替换为master）
  • 切完分支后确认当前分支的基点为上游最新提交，不存在任何历史同步操作的残留提交
• 第三步：在独立工作分支上只开展本次bug修复的操作
  • 代码修改完成、本地验证通过后，仅提交和本次bug修复相关的文件：

    git add <本次修改的文件路径>
    git commit -m "fix: 修复[具体场景]的bug"
    

  • 这个分支上绝对不要执行任何合并上游、同步其他分支的操作，保证分支历史里只存在本次bug修复的单条提交
• 第四步：推送分支并向上游发起PR
  • 将工作分支推送到个人Fork仓库：git push origin fix/[具体bug描述]
  • 在GitHub上发起PR时，对比目标选择上游主分支和你刚推送的fix工作分支。由于这个分支直接基于最新上游主分支创建，中间仅包含单条你的修复提交，PR内容不会混入任何冗余的同步提交。

已出现冗余分支的兜底修复方案 #

如果已经在混有大量同步提交的分支上完成了bug修复，不需要重新改代码，可以通过挑拣提交的方式生成干净的PR分支：

1. 基于最新的上游主分支创建干净的临时工作分支：git checkout -b fix/[具体bug描述]-clean upstream/main
2. 从之前混有冗余提交的旧分支上，把属于你自己的单条bug修复提交筛选出来：git cherry-pick <你的bug提交对应的Git哈希值>
3. 将这个干净的临时分支推送到个人Fork仓库，替换掉原来发PR用的旧分支，GitHub会自动更新对应PR的内容，最终仅保留你的单次修复提交。

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