Git工作流最佳实践：拆分大PR为依赖型双PR后的冲突与并行开发解决方案

这是我在日常团队协作中经常遇到的场景，踩过不少坑后总结出几个亲测有效的解决方案，刚好适配你的需求：

1. 让PR B始终基于PR A的分支开发，定期同步改动 #

这是最核心的做法，能从根源上避免PR A合并后PR B出现大量冲突：

• 初始分支创建：先从master拉出PR A的分支：git checkout -b feature/pr-a master，然后直接从PR A分支拉出PR B的分支：git checkout -b feature/pr-b feature/pr-a
• 同步PR A的修改：每当PR A收到评审意见并完成修改提交后，立刻切换到PR B分支执行git rebase feature/pr-a。此时如果有冲突，当场解决——因为冲突只来自PR A刚修改的小范围代码，远比等PR A合并到master后再处理要简单得多
• PR A合并后的收尾：当PR A顺利合并到master后，再把PR B分支rebase到master：git rebase master feature/pr-b，这时因为之前已经同步过PR A的所有最终改动，冲突几乎可以忽略

小贴士：千万不要用git merge来同步分支，merge会产生冗余的合并提交，让分支历史变得混乱；rebase能保持线性干净的历史，冲突解决的上下文也更清晰。

2. 用"分层topic分支"进一步降低依赖耦合（可选） #

如果PR A里包含一些独立于业务逻辑的基础改动（比如变量重命名、工具类封装、代码格式统一），可以把这部分单独拆成一个更小的PR先合并到master。这样PR A和PR B都基于这个基础分支开发，能减少两者之间的依赖范围，后续同步时的冲突概率也会更低。

3. 明确分支依赖关系，避免代码交叉修改 #

• 在PR B的描述里明确标注「依赖于PR #XXX（PR A的编号）」，这样团队评审人员会优先处理PR A，很多Git平台也会自动关联两个PR的状态
• 开发过程中，如果需要修改属于PR A范围的代码，必须回到PR A分支修改，不要在PR B分支里直接改动PR A的内容。这样能保证PR A的独立性，避免代码逻辑分散到两个分支里，后续同步时也不会出现不必要的冲突

额外的避坑建议 #

• 不要攒到最后才同步PR A的改动，建议每天或每两天同步一次，把冲突拆解成小问题解决，避免堆积成无法处理的大山
• 如果PR A的修改涉及PR B的核心业务逻辑，可以先暂停PR B的相关开发，等PR A的这部分修改确定后再继续，避免做无用功

内容的提问来源于stack exchange，提问作者NeoZoom.lua