如何对代码强制执行 PR，但允许更新 Azure Devops Git/PR/Wiki 工具中的 wiki 文件夹答案

【问题标题】：How to enforce PR for code but allow updates for wiki folders in Azure Devops Git/PR/Wiki tools如何对代码强制执行 PR，但允许更新 Azure Devops Git/PR/Wiki 工具中的 wiki 文件夹
【发布时间】：2022-07-15 22:35:11
【问题描述】：

我以为我有一个解决方案，但它似乎会导致其他问题，所以我在这里，手握帽子，为我的下一次迭代寻求一些其他想法来解决这个问题

情况是我们有一个git repo，doc文件夹中有wiki文档，其他文件夹中有代码。震惊！
我们希望将所有内容放在一个存储库中，因为它们都是相关的，并且我们希望在更新代码时更新文档。我们使用Release Flow。我们希望代码始终通过 PR。
但是，我们也希望开发人员能够通过 ADO Wiki UI 或直接提交直接更新 wiki。这适用于提交中的唯一文件位于 doc 文件夹中的情况
否则应拒绝直接提交并需要 PR（特定人员除外）

我当前的解决方案是拥有一个名为“wiki”的持久功能分支，并且这个“wiki”分支是通过 ADO wiki UI 公开的。每个夜间大师自动合并到 wiki 中，wiki 合并到 master 中，使双方都保持最新状态（无论文档更新来自何处）。这是一个普通的 fetch、checkout、pull、merge、commit、push 过程。没有异国情调的 git 开关。

然而，这似乎会创建Multiple merge basis，这有时会扰乱我们的 PR。我不认为我完全理解造成这种情况的原因，但是我们实际上是在向以前提交的功能分支添加新的更改，所以我认为这就是原因

其他一些想法可能是（按方法偏好的顺序）

使用变基而不是合并。例如将 wiki 合并到 master 并从 master HEAD 重新定义 wiki。我不确定
- 如果这是安全的 - wiki 分支本质上是共享的，并为该分支重新设置更改历史记录 - 但是没有人真正在此基础上进行建设，所以也许可以改变这段历史？）
- 如果它甚至可以消除“多合并基础”问题。我们真的希望 wiki 分支和 master 共享相同的文件
或者将 wiki 合并到 master、删除 wiki 并从 HEAD 创建一个新的 wiki 分支
- 这会混淆 wiki 工具吗？我认为分支只是一个字符串，所以如果有人当时正在积极编辑 wiki 文档，可能会有危险。
使用另一种合并方式或以某种方式手动保持两个分支同步而根本不合并（可能是 git 中允许执行此操作的某些工具，但我不知道）
- 例如从 wiki-for-all 合并 --squash 到 master，我猜 squash 没有合并父级，所以这会阻止 master 看到 wiki-for-all 分支？
- 这是我目前的首选选项，因为它看起来最简单 - 任何陷阱？
Git 子模块。我以前没有使用过这些，甚至不确定它是否会阻止我们在多个合并基础上遇到的问题。但是我认为这将意味着它不符合要求 2。如果有人对此有经验可以支持或警告，则有兴趣。
提交触发器。将 PR 策略从 Azure Devops 中引入到提交触发器中。我不喜欢这个想法，感觉晦涩难懂、复杂并且依赖于我的开发人员不熟悉的自定义 sh 代码

总体而言，如果 Azure Devops 在策略配置中提供对此用例的支持，感觉会很好。

【问题讨论】：

您为什么不希望您的文档经过某种审查和审查过程？您在分支策略上使用过滤器来降低合并文档更改的标准。
我同意@DanielMann。您写道，“我们希望在更新代码时更新文档”并假设这是常态，我认为在同一个 PR 中更改文档是首选。对于更新其他与代码更改不一致的文档，也许您可以在没有第二双眼睛的情况下盲目相信作者，但是 PR 过程是否真的有太多开销以至于需要一个完全独立的过程？
简单的答案是评论速度很慢，而且摩擦力要大得多。摩擦阻碍、延迟或拒绝参与。我们希望所有团队成员都参与进来，而不仅仅是熟悉 PR 的开发人员。我们不需要我们的文档完美，就像我们需要代码完美一样，我们需要它们由遇到它们的人维护。读者可以在几分钟内修复或澄清并继续前进。 PR是不可能的。我们已经尝试了这两种方法，低摩擦方法显然是我们的赢家。尽管有些人可能会感到惊讶，但适度并不总是等于更好的质量。
澄清最后一条评论 - 我的意思是，对于某些应用程序和指导而言，低摩擦协作与门控审核同样有效，故障排除文档适合我们。
很公平。您的生产 wiki（事实来源）是 wiki 或 master 分支吗？听起来，当人们使用 UI 时，他们直接在 wiki 上进行编辑，但同时更新 wiki 的代码 PR 将进入 master。

标签： git azure-devops azure-devops-wiki

【解决方案1】：

这个问题的答案似乎是

拥有 master 和 wiki 分支。 wiki 是没有策略的 Web UI 前端（就像我们今天一样）
使用以下 rebase/ff 进程每晚同步 master 和 wiki

git fetch 
git checkout master
git pull
git checkout wiki
git rebase master
git push --force # assuming that this is "ok" to change history on this branch as wiki UI is not holding any changes (apart from currently editing documents), it is changing individual files and committing them immediately
git checkout master
git merge wiki --ff # ensure fast forward so we don't have complex master to upset our feature PR's
git push

尚未完全证明（现有 PR 需要几天时间才能刷新），但这消除了我猜想扰乱 PR 合并引擎的持久性多合并分支

如果 Azure DevOps PR 要求策略允许仅在指定的一组分支中发生更改时允许避免 PR，那就太好了。

【讨论】：