What wiki supports feature branches?

Question

In our development workflow, like most Git-based shops, we have a production branch, a master/dev branch, feature branches where developers work on features, and release branches where things go through QA. I need a (preferably Git-based) wiki system that supports the same workflow.

It should operate something like this:

1. There's a production line of documentation.
2. When requirements for a new feature are being written, they are written in a feature branch that comes off the main line of documentation.
3. You can see the diff between production documentation and the feature branch documentation (for approval of requirements - a view of every required change).
4. Preferably you can rebase your feature branches of documentation over time so it stays up-to-date with the mainline while requirements are being completed or the software is being written.
5. When the feature (code) is merged to production, the documentation feature branch is also merged to the production documentation branch.

Basically, we want to manage our documentation exactly like our code.

Perferably this would be a wiki system that is based on Git (so we have the exact same merge process, etc.) and can be edited locally, but also has a WYSIWYG point-and-click editing environment for less tech-savvy users to use.

I was amazed when I went to try to find something like this that I couldn't find it. To me it seems so logical, but I can't find anything like it. I see Git-based wikis (looking at you Gollum), but nothing that allows branching. Does such a thing exist?

Answer 1

I think one of the only products that could allow you reasonably to use git itself to control content would be DokuWiki. This is because all of your content is stored in text files on the server file system. (Conceivably, any other wiki that operates this way is viable, but I don't know any others.)

Theoretically, your deployment repo would be inside the file system of the DokuWiki application, and if you wanted to do branch development in a remote repo, you could clone the files and edit them directly, or use a separate instance of DokuWiki itself to edit and test from a clone of the content file repo.

That said, I don't think I'd recommend this. There are probably better (or at least more supported) options that fill the same business case.

One example I'll throw out there is how Atlassian does documentation using their own Confluence product. Confluence is divided up into "spaces", which you can think of as complete wikis sharing the same application server. Atlassian creates a space for documentation of one entire product, and whenever they start working on the documentation for the next version, they copy the space in its entirety and restrict it for private editing. Then when the new version is deployed, they basically change the "space key" for the new and previous versions so that the new set of documentation is available at the same URL as the old stuff, but the older version is still accessible for people who are not up to date.