Git协作场景出现合并冲突时，分支合并顺序应如何选择？

在你描述的场景下，最优方案是将main分支合并到feature-branch分支，而非反过来，原因如下：

核心原因 #

• 维护main分支稳定性：main作为项目主分支，承载着已验证的稳定代码。如果直接在main上合并feature-branch，冲突解决过程中可能引入未经过测试的逻辑，直接破坏主分支的稳定性。而在feature-branch上合并main，开发者B可以在自己的开发分支里充分测试冲突解决后的代码，确保功能正常后再推送，不会影响主分支。
• 职责匹配更合理：feature-branch是B开发的功能分支，B对自己的代码逻辑最熟悉，在自己分支里处理冲突，能更准确地判断代码取舍，避免因不熟悉业务逻辑导致的错误。
• 保持PR流程的连贯性：解决完冲突后，B只需推送更新后的feature-branch，远程PR会自动同步修改，项目维护者A可以直接完成合并，无需在main分支做额外操作，整个PR的变更记录也更清晰可追溯。

具体操作步骤 #

1. 本地切换到你的feature分支：

   git checkout feature-branch
   

2. 拉取远程最新的main分支代码：

   git pull origin main
   

3. Git会自动检测冲突并提示，此时打开冲突文件，手动处理标记的冲突块（<<<<<<<、=======、>>>>>>>分隔的部分），保留正确的代码逻辑。
4. 冲突解决完成后，添加修改的文件：

   git add <冲突文件名>
   

5. 提交冲突解决的变更：

   git commit -m "Resolve merge conflicts with main branch"
   

6. 将更新后的feature分支推送到远程：

   git push origin feature-branch
   

例外情况 #

如果冲突涉及main分支的核心基础逻辑（比如项目配置、公共工具类），维护者A对这部分代码的背景更清楚，此时A可以在本地创建临时分支，将feature-branch合并到临时分支解决冲突，验证无误后再合并到main。但这种场景属于少数，常规情况下优先由开发者在自己的feature分支处理冲突。

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