如何解决现有Git工作流中出现的合并策略冲突问题

核心适配方案：切换为Bitbucket的Rebase, merge (rebase + merge --no-ff)合并策略 #

这是对你现有工作流改动最小、收益最高的方案，完全可以解决PR diff异常的问题，同时满足你保留合并提交记录的需求，原理如下：

• 合并feature分支到stable时，Bitbucket会先将feature的所有提交变基到stable的最新HEAD上，再生成无快进合并提交，既保留了PR合并的完整记录，又保证stable分支的提交链线性对齐
• 后续确认上线的功能合并到releasable、releasable再合并到master后，所有已上线功能的提交ID在三个分支上完全一致，Git不会再将相同内容的提交识别为变更
• 新的feature分支从master迁出后，提PR到stable前只需执行git pull --rebase origin stable将本地分支变基到stable最新版本，PR的diff就只会展示当前feature的独有改动，不会出现全量文件变更的问题

配套工作流微调（仅新增2个无负担操作） #

• 所有feature分支提PR前必须先执行git pull --rebase origin stable，解决冲突后再推送代码，保证PR基准永远和stable对齐
• 每次releasable合并到master完成发布后，执行一次master到stable的合并操作，该操作只会带入已上线的生产代码，不会引入未上线功能，可定期清理两个分支的提交历史差异

备选方案（无需修改现有合并策略） #

如果暂不希望调整PR合并策略，可调整上线功能的合并逻辑：确认要上线的功能不要直接从feature分支合并到releasable，而是从stable分支cherry-pick对应feature的合并提交到releasable，保证两个分支的合并提交ID完全一致，后续合并到master后也不会出现提交树分叉的问题。

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