Git Flow合并异常：Release到Master再回Dev后PR大量冲突

问题原因 #

核心问题是长期未将master分支的更新合并回development，导致两个分支的提交历史出现严重分叉。本次发布仅同步了release分支上的热修复内容，并没有补全master和development之间累积的历史差异。Git合并时依赖共同的基准提交来识别变更，当两个分支的共同祖先过于陈旧，且中间没有同步记录时，Git会认为几乎所有文件的内容都存在冲突，而非仅实际修改的部分。

解决步骤 #

1. 定位共同祖先提交
   先找到master和development最近的共同历史节点，执行命令：

   git merge-base master development
   

   记录返回的提交哈希值。

2. 创建临时分支同步历史差异

   • 基于共同祖先创建临时分支：

     git checkout <共同祖先哈希>
     git checkout -b temp-sync
     

   • 先合并master到临时分支，一次性处理master端累积的变更冲突：

     git merge master
     

     手动解决所有冲突后提交。
   • 再合并development到临时分支，处理development端的变更冲突：

     git merge development
     

     解决剩余冲突后提交。

3. 替换development分支并同步远程

   • 切换回development分支，重置到临时分支的状态：

     git checkout development
     git reset --hard temp-sync
     

   • 若development是远程分支，需强制推送更新（提前和团队成员沟通，避免影响协作）：

     git push origin development --force
     

4. 建立长期同步规范
   后续严格遵循Git Flow流程：每次master分支有更新（包括release分支合并、hotfix分支合并），立即将master合并回development，避免历史分叉再次累积。

合并策略的影响 #

不同合并策略无法解决历史分叉的根本问题，只会改变冲突出现的形式或处理难度：

• Rebase：将development的提交重新基于master的最新提交，本质是改写提交历史。历史分叉严重时，会逐个提交触发冲突，处理成本更高，且多人协作时会导致其他成员的本地分支与远程分支不一致。
• Squash Merge：将development的多个提交压缩为一个合并到master，虽然能简化master的提交历史，但会丢失development的详细提交记录，且无法修复分支的历史分叉问题，下次合并仍会出现大量冲突。
• No-Fast-Forward Merge：仅保留合并提交的节点，但如果两个分支没有有效的共同基准，Git仍无法识别实际变更，依然会触发全量文件冲突。

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