类GitFlow工作流下解决release分支合并冲突的Git合并策略咨询

你需要的「将release分支提交逐个应用到production、自动跳过已存在提交」的需求完全可以实现，优先通过调整操作方式+变基操作解决，比单纯换合并策略效果更稳定。

操作方案 #

优先推荐：调整工作流+rebase操作（从根源避免冲突） #

热修复流程优化（从根源避免提交重复）

• 热修复不再从master分支拉取，改成直接从production分支检出hotfix/*分支开发
• 修复验证完成后先提PR合并到production上线
• 再将hotfix/*分支合并回master，保证master永远包含production的全部提交，后续从master拉取的release分支天然包含热修复代码，不会出现提交重复问题

发布release时的操作

• 正式提交发布PR前，先将本地release/*分支基于最新的production分支变基：

  git checkout release/*
  git pull origin production
  git rebase production
  

  变基过程中Git会自动识别已经存在于production分支的提交（包括之前的热修复提交）直接跳过，只有release分支独有的新提交会被逐个应用，过程中只会存在真实的代码修改冲突，不会出现重复提交导致的无意义冲突。
• 变基完成后如果之前已经推送过release分支到远端，使用git push --force-with-lease origin release/*安全覆盖远端分支
• 再提交PR将变基后的release/*合并到production，此时不会再出现大量冲突

临时方案：使用优化的合并参数（不调整现有工作流的折中选择） #

如果暂时无法调整现有热修复流程，合并release到production时可以使用带参数的递归合并策略减少冲突：

git merge -s recursive -X patience --no-ff release/*

patience参数会优化大代码块变动时的diff逻辑，减少因为提交顺序不一致导致的误判冲突，不过该方案只能降低冲突概率，无法完全避免重复提交带来的问题。

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