How to use Git for MediaWiki page versioning and collaboration

MediaWiki already tracks every edit in its database, but that history is server-bound. If your team works with Git — reviewing commits, branching, offline editing — you can pull the wiki's pages into a Git repository and push changes back into the wiki. The bridge that makes this possible is git-remote-mediawiki, a tool that has existed for over a decade and is still the standard way to connect MediaWiki with Git. This guide covers what it does, its honest limitations, and the workflow that fits a small-to-medium wiki.

What git-remote-mediawiki does

git-remote-mediawiki is a standalone Perl script that acts as a Git remote transport: git clone git-remote-mediawiki::https://your.wiki/ wiki-copy fetches every page — including its full edit history, each revision becoming a Git commit — and git push replays your local commits back to the wiki as edits via the MediaWiki API. The other direction also works: it can clone, fetch from and push to a MediaWiki installation without any server-side component (no extension to install; the standard API is enough).

The project is maintained on GitHub (moy/Git-Mediawiki); it is the renamed continuation of what was once part of MediaWiki core. Installation is just the script in your PATH, and it needs Perl. Once it's on the path, Git recognizes the remote type automatically.

Getting the script

git clone https://github.com/moy/Git-Mediawiki.git
ln -s "$PWD/Git-Mediawiki/git-remote-mediawiki" /usr/local/bin/git-remote-mediawiki

Cloning a wiki

git clone git-remote-mediawiki::https://your.wiki/wiki my-wiki
cd my-wiki

Each page becomes a file named after its title (spaces become underscores), and the full revision history of every page is replayed as commits with the original authors and timestamps. A page-edit history of a few hundred pages clones in minutes; a wiki in the thousands of pages starts to take a while — this is the tool's main scaling limit.

Working locally and pushing back

# Edit page files with your favourite editor
vim Main_Page

# Commit like any Git project
git add Main_Page
git commit -m "Improve the intro of the main page"

# Replay commits into the wiki as edits
git push

Details that make the workflow behave:

• Remote pages win conflicts — if someone edited a page on the wiki since your last fetch, your push of that page is rejected; resolve by rebasing on origin (fetch first, then merge or rebase), then push again
• Page moves and deletes — renaming a file in Git renames the page; deleted files can be pushed as page deletions (the tool supports it, which is useful for removing spam offline — but test on a scratch wiki first, since it is the most destructive operation)
• Namespaces — files map to pages by name; a page like Template:Infobox becomes the file Template:Infobox, editable exactly like any other
• Binary uploads are not synced — files in File: namespace tracks text (the file description page) but not the binary content, which stays with MediaWiki's images/

A review workflow around the repo

Because the clone is a normal Git repository, the collaboration model is yours to choose:

1. Make a branch per topic: git checkout -b policy-tweaks
2. Edit and commit locally, squash typo-fix commits: git rebase -i
3. Push the branch to a shared Git host (GitHub/GitLab/Gerrit) and review the diff like code
4. Push the merged branch to the wiki: git push origin policy-tweaks:master — hmm, check the refspec — with git-remote-mediawiki the push target is the wiki branch (origin tracks the wiki); after review, merge the branch into master locally and git push origin master

This keeps wiki content under the same review discipline as code, with full history and attribution.

Honest limitations

• Scale — the tool's own documentation recommends it for wikis up to roughly a thousand pages, or when only a small set of pages/categories needs offline work. Above that, fetch/push cycles become slow, and the full history download on first clone grows linearly with page count
• Concurrent editing — this is not real-time collaboration. Two people working on the same page offline will hit conflicts; the tool has no merge support beyond Git's
• No short code paths — templates, Lua modules and other text-based content work fine, but anything stored only as binary uploads (images, PDFs) is outside its scope
• Maintenance level — it is a mature but community-maintained tool; expect conservatively tested features rather than rapid development

Alternatives for different jobs

• Version control of the codebase, not the pages — if what you want to track is your MediaWiki installation files (extensions, LocalSettings.php, skins), that is a plain Git repository of the install; the GitIntegration extension helps sync the content of such a repo with the live install
• Content export (one-way) — for archival or backup without bidirectional sync, the built-in XML dump (maintenance/dumpBackup.php) plus importing the dump into a Git repo is simpler and handles any wiki size; several community tools script exactly this
• On-wiki review — if the goal is only better change review without Git, MediaWiki's own history, watchlists and the FlaggedRevs extension provide an in-wiki alternative

When it makes sense

The sweet spot: a documentation-heavy wiki with a single-digit-thousand page count, maintained by people who already live in Git. You get offline editing, branching experiments, code review on content changes, and portable full history — while the wiki itself stays untouched. If your wiki is large, rapidly edited by many non-technical users, or needs real-time co-editing, stick with the wiki's own tools; git-remote-mediawiki shines precisely in the developer-driven middle ground.