如何逐步解决Git合并冲突并拆分独立的冲突解决提交

首先澄清规则边界：你提到的「严禁对公共分支执行变基」是协作层面的约束，仅针对已经推送到公共远程、被其他协作者拉取作为开发基础的提交，你本地未推送的个人开发分支属于私有工作区，对这部分内容做变基操作完全合规，不存在破坏公共历史的问题。

以下都是Git官方支持、业界普遍采用的标准工作流，不属于临时变通方案：

方案1：分阶段提交冲突解决（最通用，无历史重写风险） #

这个方案全程不会修改任何已有提交，完全基于普通merge流程实现，适合所有协作场景：

• 启动合并时禁止自动生成合并提交：git merge --no-commit --no-ff origin/dev
• 此时Git会停在冲突待解决状态，不要一次性处理所有冲突，先挑选第一组逻辑关联的冲突（比如仅处理支付模块相关的冲突文件/代码块），无关的冲突文件保持未解决状态即可
• 这组冲突处理完成后，仅把这部分解决完的文件加入暂存区：git add <对应文件路径列表>
• 直接提交这部分冲突解决，写入对应语义的提交信息：git commit -m "merge: resolve payment module conflicts synced from dev"，此时Git不会终止整个合并流程，剩余未解决的冲突会被保留
• 重复上述流程：处理下一组关联冲突、暂存对应文件、提交并写清楚本次解决的冲突范围，直到所有冲突全部处理完成
• 最后一笔冲突提交完成后，整个合并流程自动结束，Git会完整保留合并的追踪关系，所有提交历史都是公开可追溯的，没有任何历史重写操作。

方案2：本地分支交互式变基（冲突和原有提交语义绑定） #

如果你希望冲突解决直接归入对应功能的原有提交，而不是单独生成merge相关的冲突解决提交，可以在你的个人开发分支（未推送到公共远程、或仅你自己使用的个人远程分支）上使用交互式变基：

再次强调：变基的禁忌只有「重写他人已经基于其开发的公共提交」，你自己本地的私有提交怎么改都不违反协作规则。

• 先拉取远程最新的dev分支代码：git fetch origin dev
• 启动交互式变基，将你在当前分支的所有提交逐笔重放到最新的dev分支之上：git rebase -i origin/dev
• 变基过程中，每处理到你的一笔个人提交出现冲突时，只解决和这笔提交功能逻辑相关的冲突，解决后执行git add <对应文件>，再执行git rebase --continue，这部分冲突解决会直接归入当前这笔功能提交中，不会和其他功能的冲突混在一起
• 如果单笔提交对应的冲突跨多个不相关逻辑，可以在变基过程中执行git rebase --edit-todo，将当前提交拆分为多笔粒度更细的提交，分别解决对应冲突后再继续流程
• 变基全部完成后，如果你之前已经把这个个人分支推送到自己的远程个人开发分支，使用git push --force-with-lease推送即可，这个操作只会影响你自己的个人分支，不会触碰dev等公共分支的历史。

方案3：基于worktree拆分大冲突的处理上下文 #

如果单次同步的冲突量极大，跨多个完全独立的业务域，你可以用Git原生的worktree能力给不同模块的冲突创建独立工作目录，避免在同一个工作区混改不同逻辑的代码：

• 先在主工作区启动和dev的合并，停在冲突状态：git merge origin/dev
• 给每个独立业务域的冲突创建单独的工作树：git worktree add ../resolve-conflict-payment HEAD、git worktree add ../resolve-conflict-user HEAD
• 在每个独立工作目录中只处理对应域的冲突，解决完成后生成独立的语义化提交
• 所有冲突都处理提交完成后，将这些提交逐一合并回你的主开发分支，最后清理临时工作树即可：git worktree remove ../resolve-conflict-payment

注意：不要为了整理冲突解决提交随意使用git reset等操作篡改已经推送到公共区域的提交，只要遵守「公共提交历史不可重写」的核心原则，上述所有操作都是团队协作中被广泛认可的标准做法。

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