Azure DevOps如何强制代码走PR且允许wiki文件夹直接更新

当前团队Git仓库使用规则与流程约束如下：

• 仓库内doc文件夹存放wiki文档，其余目录存放业务代码
• 所有内容必须统一存放在同一仓库，方便代码更新时同步修改文档；团队采用Release Flow流程，要求代码变更必须通过PR才能合入
• 若单次提交仅涉及doc文件夹下的文件，允许开发者直接通过ADO Wiki UI或直接提交更新wiki内容
• 除指定人员外，所有涉及非doc文件夹的直接提交必须被拦截，强制走PR流程

当前方案与故障根因 #

当前实现逻辑：创建持久化特性分支wiki，将该分支配置为ADO Wiki的映射数据源，每日夜间自动执行双向同步：先将master分支合并到wiki分支，再将wiki分支合并回master，保证两侧内容一致。同步流程使用标准的fetch/checkout/pull/merge/commit/push操作，未使用特殊Git参数。
该方案会触发**多合并基（Multiple merge basis）**问题，偶尔导致PR流程异常，根因是持续向已经完成合入的特性分支追加新变更，导致两个分支的提交拓扑反复交叉，合并基不再唯一。

方案1：用rebase替代merge #

操作逻辑：先将wiki分支合并到master，再基于master的HEAD对wiki分支执行rebase。

• 可行性：只要确认没有开发者基于wiki分支拉取本地分支开发，修改共享分支历史是完全可接受的——ADO Wiki本身只读取分支的最新HEAD提交，不依赖提交历史链。
• 效果：rebase会把wiki分支上独有的提交全部重放到master最新提交之后，从拓扑上彻底消除交叉合并带来的多合并基问题，能保证两个分支的doc目录内容完全一致。
• 风险：如果同步窗口期有用户正在通过Wiki UI提交变更，rebase强推之后可能导致用户端推送失败，需要给同步脚本加失败重试逻辑；另外rebase后必须用--force-with-lease推送到远端，禁止用普通--force避免覆盖窗口期的新提交。

方案2：全量重建wiki分支 #

操作逻辑：先将wiki分支合并到master，删除原有wiki分支，再从master的HEAD新建同名wiki分支。

• 可行性：ADO Wiki映射的是分支名对应的最新提交，只要重建分支的间隔足够短（脚本执行通常在秒级），不会导致Wiki工具异常。
• 效果：完全重置分支拓扑，从根源上消除多合并基问题，内容一致性可以100%保证。
• 风险：如果重建分支的瞬间有用户正在提交Wiki编辑，推送到旧分支的提交会随着分支删除被清掉，需要手动重新提交，体验很差；另外删除重建分支会清空wiki分支的独立提交历史，如果后续需要审计Wiki侧的历史变更会比较麻烦。

方案3：用squash merge实现同步（最推荐的落地方案） #

操作逻辑：每次同步时，用merge --squash把wiki分支的文档变更压缩成单个提交合入master，同时直接把master的HEAD用--force-with-lease推送到wiki分支覆盖原有内容，不需要做反向merge。

• 可行性：squash合入不会保留两个分支的父节点关联，master分支上只会新增一个包含所有文档变更的普通提交，不会形成交叉合并的拓扑，从根本上避免多合并基问题。
• 效果：因为每次同步后直接用master的最新内容对齐wiki分支，两个分支的文件内容可以做到完全一致，没有遗留合并冲突的隐患。
• 潜在陷阱：
  • 必须保证同步任务串行执行，不能在上一次同步没完成时启动下一次同步，否则会出现提交覆盖的问题
  • 覆盖wiki分支时必须用--force-with-lease参数，一旦发现远端wiki分支有窗口期的新提交就终止本次同步，留到下一个周期再处理，避免覆盖用户刚提交的Wiki内容
  • squah合入master的提交信息要规范标注为Wiki同步提交，避免和普通业务提交混淆

方案4：使用Git submodule #

• 可行性：完全不满足需求。submodule本质是把文档存放在独立的Git仓库中，只是在主仓库里记录子仓库的提交哈希，不符合“文档与代码存放在同一仓库”的要求。
• 额外风险：submodule的学习成本高，团队成员很容易出现子模块提交指针不更新、拉取代码漏拉子模块内容的问题，反而会提升文档与代码版本不一致的概率，完全不适合当前场景。

方案5：自定义提交触发器做校验 #

• 可行性：技术上可以实现，但性价比极低。需要自己写脚本拦截所有直接推送到master的提交，判断提交涉及的文件路径，再做权限校验，还要处理各种边界情况（比如合并提交、部分回滚提交的路径识别问题）。
• 风险：自定义脚本的维护成本高，一旦脚本出bug要么会拦截正常提交，要么会放过违规的直接提交，稳定性远不如ADO原生的分支策略，不推荐采用。

落地建议：优先选择方案3，同步频率可以从每日一次调整为每小时一次，缩短Wiki变更同步到master的延迟，同时把同步任务的首次执行时间放在团队非工作时段，进一步降低用户编辑冲突的概率。确实如反馈所说，期待ADO后续能原生支持“按路径配置分支提交权限、直接映射仓库指定目录为Wiki数据源”的能力，省去额外开发分支同步逻辑的成本。

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