Git基于PR工作流中依赖分支的处理问题咨询

背景 #

基于PR工作流，从master分出两个分支：

• branchA：库变更，已有PR在评审，修改了API
• branchB：依赖该库的应用，已有PR在评审，需要适配branchA的API变更

当前验证方式是在branchB执行git fetch && git merge branchA来验证适配，但遇到两个问题：PR推送时branchB包含branchA的文件；Jenkins CI中两个PR都构建失败。

问题1：如何维护这两个存在依赖的PR，确保各自仅包含需评审的文件？ #

别用merge，改用两种更稳妥的方式：

• 方案一：本地验证用rebase，不推送修改后的分支
  在branchB本地执行：

  git fetch
  git rebase origin/branchA
  

  验证完适配没问题后，直接重置回原分支状态：

  git reset --hard origin/branchB
  

  这样你的PR里只会保留branchB自己的适配代码，不会混入branchA的文件。
• 方案二：创建临时分支做验证
  从branchB拉一个临时分支：

  git checkout -b temp-branchB branchB
  git merge branchA
  

  在temp-branchB上完成验证，确认没问题后切回branchB推送PR即可，完全不会影响原分支内容。
• 补充：如果要让评审者看到适配效果，直接在PR描述里说明依赖branchA的PR，让评审者自己本地合并验证就行，PR本身只提交branchB的代码。

问题2：我们处理CI的方式是否正确，即先禁用应用构建待库变更合并后再启用？ #

这种方式太繁琐还容易误操作，完全没必要，换这几种高效方式：

• 给CI配置依赖PR的预构建逻辑：在branchB的CI任务里，临时拉取branchA的代码替换库依赖（比如npm包用npm install git+ssh://git@xxx/xxx.git#branchA，本地子模块直接切到branchA），这样CI能直接验证适配后的代码，不用等branchA合并。
• 给PR加标签或状态标记：比如给branchA加ready-for-depends标签，CI配置成只有当branchA带这个标签时，branchB的CI才运行；或者在branchB的PR描述里关联branchA的PR号，CI自动识别并拉取对应分支代码构建。
• 临时调整CI触发规则：让branchB的CI只在手动触发时运行，比禁用整个应用构建灵活，不会影响其他PR的CI。

问题3：是否应在各自PR评审通过后，经内部讨论合并分支创建一个大PR推送？ #

不建议这么做，会破坏PR的独立性，增加评审复杂度。正确做法是：

• 优先完成branchA的评审和合并：确保库的API变更被认可，合并到master后，branchB再基于最新master做rebase，然后推送PR，这样branchB的PR只会包含适配代码，评审和CI都能正常进行。
• 如果必须同时上线，用合并队列：很多代码托管平台（GitHub、GitLab等）都支持合并队列，把两个PR加入队列，平台会自动处理依赖关系，先合并branchA再合并branchB，既保证上线顺序，又保留各自的PR评审记录。
• 特殊情况：如果branchA还在评审，但branchB的适配需要提前评审，直接在branchB的PR里明确标注依赖branchA的PR，评审者可以本地合并branchA来评审，等branchA合并后，branchB再rebase master重新跑CI即可。

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