特性分支落后master无文件冲突时合并PR是否必须先同步master

问题1：无文件修改重叠时，合并PR前是否必须同步master到特性分支？行业最佳实践是什么？ #

不是必须同步，不存在强制要求。
Git的文本层面合并逻辑只识别两边分支对同一文件同一位置的修改差异，只要两个分支修改的文件完全无重叠，就不会产生文本合并冲突，直接合并不导致文件内容错误。
行业内没有统一强制标准，通用实践根据团队CI/CD流程选择即可：

• 如果团队CI校验仅在特性分支推送时触发、不会在合并阶段自动基于最新master做预合并校验，建议合并前同步master，避免出现「文件不重叠但代码逻辑冲突」的问题（比如特性分支修改了A文件的函数返回值结构，master新增的B文件代码调用了该函数，两边文件不同但逻辑不兼容，这类问题文本合并不会报错，但上线会出bug）
• 如果团队配置了合并阶段的预合并CI校验、或者合并后会立刻触发全量主干测试，不需要提前同步，减少无意义的合并提交污染主干历史
• 如果团队主线要求线性历史，同步时优先用git rebase master而非直接生成merge commit，保持提交记录整洁

问题2：不同步master直接合并PR，是否会保留master上B/C/D文件的最新内容，仅更新A文件？ #

是的，结果完全符合你的预期。
Git合并不会回退或覆盖目标分支上未被源分支修改的内容：你的特性分支从创建后仅对A文件有提交，从未修改过B、C、D三个文件，合并时Git只会把特性分支对A的改动应用到主干，B/C/D会完整保留master上的最新版本，不会被特性分支上的老版本覆盖。

注意：这个结论的前提是特性分支确实没有对B/C/D做过任何提交（包括误提交的回退、权限修改等操作），和你描述的场景完全匹配。

问题3：Fast forward不可用的前提下，Merge Commit和Squash选项能否正常完成合并？ #

两个选项都可以正常完成合并，不会报错。
首先解释Fast forward不可用的原因：快进合并要求特性分支的提交是master最新提交的直接后继，也就是两个分支没有分叉，当前master比特性分支多了一笔提交，历史已经分叉，自然不满足快进条件。
两个可用选项的合并后文件内容完全一致，仅提交历史有区别：

• 选择Merge Commit：Git会自动生成一笔新的合并提交，完整保留特性分支上的所有提交记录、以及master上新增的B/C/D提交记录，主线历史可以追溯到特性分支上的每一笔改动
• 选择Squash：Git会把特性分支上所有针对A文件的提交压缩成1笔新的提交合入master，特性分支上的多笔零散提交不会出现在主线历史中，主线记录更简洁，适合特性分支上有大量调试、临时提交的场景

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