如何在GitHub上将提交拆分为独立PR且不影响未合并提交

我完全懂你的顾虑——刚提的PR还在等机器人合并，想继续贡献又怕新PR带上旧提交，还担心rebase搞砸已有的PR，确实挺头疼的。别慌，按下面的步骤来就能轻松解决：

核心原则：用独立分支隔离不同PR的开发 #

你之前在本地master上开发第一个PR，现在要避免继续在这个分支上叠加新功能，而是基于上游仓库的master创建全新分支，这样新分支完全干净，不会包含任何旧提交。

步骤1：确保本地关联上游仓库 #

如果还没添加上游仓库的远程地址，先执行：

git remote add upstream <原仓库的Git地址>

步骤2：创建干净的新分支开发新功能 #

先拉取上游仓库的最新代码，再基于上游master创建新分支：

# 拉取上游所有分支的最新内容
git fetch upstream
# 创建并切换到新分支，分支名自己取，比如new-auth-feature
git checkout -b new-auth-feature upstream/master

现在这个新分支就是上游仓库的最新状态，和你之前的提交完全无关。在这个分支上开发新功能，提交后推送到自己的fork仓库，再创建PR就不会包含旧提交了。

关于等待合并的PR和本地master的冲突问题 #

你担心rebase会删除PR代码、导致PR失效，这个顾虑是对的——不要在PR合并前强制推送修改后的本地master到你的fork仓库，因为你的PR是基于fork的master版本，强制推送会覆盖PR的提交历史，搞乱审核流程。

稳妥的做法：等机器人合并后再同步本地master #

既然PR已经被接受，只是等自动合并，那完全可以先放着本地master不管，等合并完成后再同步：

# 切换到本地master
git checkout master
# 拉取上游最新代码
git fetch upstream
# 把本地master重置为上游master的状态（因为你的提交已经被合并了）
git reset --hard upstream/master
# 推送到自己的fork仓库，同步状态
git push origin master

如果现在非要处理本地master的冲突（可选） #

要是你想提前让本地master同步上游，也可以操作，但绝对不能推送到fork的master：

1. 先备份当前本地master，防止操作失误：

   git checkout master
   git branch master-backup
   

2. 尝试rebase上游master：

   git fetch upstream
   git rebase upstream/master
   

3. 手动解决冲突，完成rebase后，本地master就同步了上游且包含你的提交，但此刻不要执行git push origin master，等机器人合并PR后再推送。

关键提醒 #

• 每次开发新功能都要从upstream/master拉新分支，不要在已有PR的分支上叠加开发，这样所有PR都是独立的，互不干扰。
• 已提交PR的分支（比如这次的fork master），在PR合并前不要做任何强制推送操作，避免破坏PR的提交历史。

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