如何优化GitHub工作流实现同一分支持续开发与新PR提交

你当前的工作流里有不少可以完全省略的冗余步骤，尤其是「PR合并失败就从旧分支拉新分支迭代」的操作，不仅会堆积大量零散无用的分支，还会让提交历史越来越混乱，后续同步代码、排查问题的成本会越来越高。下面的方案可以在尽可能少切换分支的前提下，把整体流程压到最短。

先纠正几个常见的认知误区 #

• 只要分支没有被删除，你往远程同一个开发分支推新提交，这些提交会自动同步到该分支关联的已有PR中，根本不需要为了修改冲突、回应评审反复新建分支
• 合并失败（存在代码冲突）不是开新分支的理由：冲突的本质是你的分支落后于主干代码，只需要在当前开发分支上同步最新主干、解决冲突，就能自动消除原PR的冲突标记
• 从旧的未合并分支拉新分支开发，是导致后续分支缠成一团的核心原因：如果是做独立的新需求，永远要从最新的主干切分支，不要从带旧未合并提交的分支拉新分支，不然你的PR里会混进大量和当前需求无关的变更。

具体落地的极简工作流（完全匹配减少分支操作的需求） #

场景1：当前开发分支上的PR被打回/存在冲突，需要迭代修改 #

全程不需要开新分支，所有操作都在原有开发分支上完成：

1. 先把本地主干的最新代码同步到当前开发分支，执行：

   git pull origin master --rebase
   

   这个操作会把你本地的所有开发提交，摞在最新的主干代码之上，不会产生多余的无意义merge节点，历史更干净
2. 解决同步过程中出现的代码冲突，确认所有功能正常
3. 把解决完冲突的代码推回远程的原有分支：

   git push origin branch_a
   

   推送完成后，原来关联这个分支的PR会自动更新所有新的提交，原PR的冲突状态会自动消失，根本不需要重新开PR。

场景2：当前分支上的PR已经合并到主干，需要开发新的独立需求 #

这个环节也完全不需要反复切换多个零散分支，固定走两步即可：

1. 先切回本地主干，拉取最新的主干代码：

   git checkout master && git pull origin master
   

2. 基于最新的主干代码切出对应新需求的开发分支即可，比如新需求是做用户权限调整，就执行：

   git checkout -b feature/user-permission
   

   这里切记不要从之前的旧开发分支切新分支，否则你新做的需求会带着旧分支上已经合并过的重复提交，PR里会出现大量无关的变更。

关于「始终在同一个分支持续开发、多次提交开新PR」的操作可行性 #

这个操作在技术上完全可以实现：主流代码托管平台都支持选择同一个分支上的不同提交范围、指向不同的目标分支创建独立PR，哪怕你所有提交都推在同一个branch_a上，也能拆分出多个独立的PR。
但非常不推荐这种操作：这种模式下你的分支历史会完全变成流水账，不同需求的提交全部缠在一起，后续如果需要回滚某个需求、或者拆分不同的功能版本，会带来极高的维护成本，多人协作时其他协作者拉取这个分支也会完全搞不清提交对应的业务逻辑。

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