How to enforce PR for code but allow updates for wiki folders in Azure Devops Git/PR/Wiki tools

Question

I thought I had a solution for this but it seems it causes other problems so I am here, cap in hand, asking for some other ideas for my next iteration to solve this problem

1. Situation is that we have a git repo, wiki documentation in doc folder, code in other folders. Shock!
2. We want it all together in one repo as it is all related and we want to update the docs as we update the code. We use Release Flow. We want code to always go through a PR.
3. However we also want developers to be able to directly update the wiki through the ADO Wiki UI or via a direct commit. This applies if the only files in the commit are in the doc folder
4. Otherwise direct committing should be denied and a PR required (except for specific people)

My current solution is to have a persistent feature branch called "wiki" and this "wiki" branch was exposed via the ADO wiki UI. Each night master is automatically merged into wiki and wiki merged into master bringing both sides up to date (regardless of where doc updates came from). This is a vanilla fetch, checkout, pull, merge, commit, push procedure both ways round. No exotic git switches.

However this appears to create Multiple merge basis which messes up our PRs on occassion. I don't think I fully understand the causes for this however we are essentially adding new changes to a previously committed feature branch, so I think this is the reason

Some other ideas might be (in order of approach preference)

• Use rebase instead of merge. e.g. merge wiki to master and rebase wiki from master HEAD. I'm not sure
  • if this is safe - wiki branch is essentially shared and rebase changes history for the branch - however no-one is really building on top of it, so maybe it is ok to change this history?)
  • if it will even remove the "multiple merge base" issue. We really want both wiki branch and master to share the same files
• Alternativaly merge wiki to master, delete wiki and create a new wiki branch from HEAD
  • will this confuse the wiki tool? I think a branch is just a string, so perhaps the danger is if someone is actively editing a wiki document at that time.
• Use another flavour of merge or somehow manually keeping the two branches synchronised without merging at all (probably some tool in git that allows doing this that I'm not aware of)
  • e.g. merge --squash from wiki-for-all into master, I guess that squash doesn't have a merge parent so this will prevent master from seeing the wiki-for-all branch at all?
  • this is my current preferred option as it seems simplest - any traps?
• Git submodule. I've not used these before and not even sure if it will prevent the problem we are having with multiple merge bases. However I think it will mean that it fails requirement 2. Interested if anyone has experience to endorse or caution for this purpose.
• Commit trigger. Bring the PR policy out of Azure Devops and into a commit trigger. I don't like this idea, it feels obscure, complex and relies on custom sh code which my developers aren't familiar with

Overall it feels like it would be nice if Azure Devops provided support for this use case in the policy configuration.

Answer 1

The answer to this seems to be

• to have master and wiki branches. wiki is the web UI front end with no policies (as we have today)
• synchronise master and wiki nightly with the following rebase/ff process

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

Not fully proven yet (will take a few days for existing PRs to flush through) but this removes the persistent multi-merge branch that I guess was upsetting the PR merge engine

It would still be nice if the Azure DevOps PR requirement policy could allow avoiding a PR if only changes in a specified set of branches.