GitHub无法识别已合并文件，GitOps PR体系落地后分支合并冲突异常

合并冲突反复出现的原因 #

合并冲突反复出现的核心原因是GitHub squash and merge 策略的固有特性，并非系统异常：
squash and merge 会将源分支的所有提交压缩为一个全新的独立提交合入目标分支，不会生成标准合并提交，也不会记录两个分支的共同祖先关联关系。将合并了main的修复分支压缩合入develop后，develop上仅存在一个内容包含main hotfix的压缩提交，和main上的原始hotfix提交哈希完全不同、没有祖先关联。
此时Git进行分支比对时，仍然会使用合入hotfix之前的旧提交作为两个分支的共同祖先，因此从develop向main提PR时会提示冲突；但由于两个分支的实际文件内容已经对齐，再次合并时Git会提示无变更需要合并。

PR展示异常的原因 #

GitHub的PR提交、变更预览逻辑会对分支比对结果做缓存优化，和Bitbucket的实时计算逻辑不同。当分支的祖先链发生变更（比如压缩合入、变基操作）但缓存未更新时，就会出现提交记录过时、变更文件展示异常的问题。

修复当前分支冲突（无需解除develop分支保护） #

• 本地执行git fetch origin拉取远端最新的main和develop分支代码
• 从最新的origin/develop拉取临时修复分支：git checkout -b fix/align-main-develop origin/develop
• 执行合并命令生成祖先关联记录：git merge -s ours origin/main，该命令会生成一个标准合并提交，完全采用当前develop的内容，不会产生冲突，仅用于告知Git两个分支已经完成同步
• 将临时分支推送到远端，提交PR走正常评审流程合入develop即可
• 合入完成后再提交develop到main的PR，Git会识别到新的共同祖先，不会再提示冲突

修复PR展示异常 #

• 进入展示异常的PR页面，点击右上角「Edit」按钮，将目标分支临时切换为任意其他分支，再切回原目标分支，即可触发GitHub重新计算分支比对结果、清空旧缓存，展示正确的提交和变更内容

后续操作规范 #

核心分支（main、develop）之间的同步操作禁止使用squash and merge，仅特性分支合入核心分支时可使用该策略。核心分支同步必须使用标准合并提交（GitHub对应Create a merge commit合入选项），保留完整的分支祖先链，避免后续重复出现同类问题。

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