How to use Git for MediaWiki page versioning and collaboration

Why put a wiki under Git?

MediaWiki already tracks every edit in its database, but that history lives only on the server. By pulling the wiki into a git repository you get:

• offline access to the full page tree.
• the ability to create branches, squash commits and cherry‑pick changes.
• a familiar workflow for developers who already use Gerrit or GitHub.
• portable backups – a .git directory is all you need.

Prerequisites

• Git (any recent version).
• Access to the target MediaWiki instance (read‑only works, but push requires a user account with edit rights).
• Optional: git‑remote‑mediawiki – a helper script that turns a wiki into a remote.

Step 1 – Install git‑remote‑mediawiki

On a Unix‑like system:

# Clone the helper (the script lives in the MediaWiki repo)
git clone https://gerrit.wikimedia.org/r/mediawiki/core.git ~/mw-core
# The executable is git-remote-mediawiki under extensions/Git-Mediawiki
cp ~/mw-core/extensions/Git-Mediawiki/git-remote-mediawiki /usr/local/bin/
chmod +x /usr/local/bin/git-remote-mediawiki

If you are on Windows, place the script somewhere in %PATH% and make sure git.exe can execute it.

Step 2 – Clone the wiki

Use the helper as a remote name. Replace https://example.org/wiki with the public URL of your wiki.

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

The command fetches every page as a plain text file in the repository. Each page becomes a file named after its title (spaces become _ by default). The full edit history is stored as normal Git commits.

Step 3 – Make changes locally

Edit any page with your favourite editor. For example:

vim "Main_Page"
git add Main_Page
git commit -m "Improve the intro of the Main Page"

You can create branches to experiment without affecting the main line:

git checkout -b feature/faq-updates
# … edit a bunch of pages …
git commit -a -m "Add new FAQ entries"

Step 4 – Push changes back to MediaWiki

The helper translates Git commits into MediaWiki edit API calls. A simple git push will replay the commits in order.

git push origin master

If the remote rejects a change (e.g. because another editor edited the page in the meantime) you will see a merge conflict. Resolve it locally and push again.

Step 5 – Collaboration workflow

Because the repository is a regular Git repo you can use any collaboration model you prefer:

• Feature branches + pull requests – push a branch to a shared remote (e.g. a Gerrit repository) and ask reviewers to merge it.
• Squash & rebase – keep the wiki history tidy by squashing small typo fixes before pushing.
• Code review tools – Gerrit, GitLab or GitHub can be used to comment on each commit, exactly as you would for source code.

All of this works without changing the MediaWiki installation itself; the only thing you need on the server side is the standard MediaWiki API.

Best‑practice .gitignore

MediaWiki stores binary uploads in images/. Those files are not suitable for Git, so add a simple ignore file:

# Ignore uploaded files – they are managed by MediaWiki, not Git
images/*
# Keep the configuration files you want versioned
!LocalSettings.php

Never commit LocalSettings.php to a public repo if it contains passwords; keep credentials in a separate, ignored file and source them from LocalSettings.php instead.

Limitations

• The helper scales reasonably up to a few thousand pages. Larger wikis (> 1 000 pages) become slow because the script has to download the full revision history.
• Only text pages are represented. Templates, modules and other MediaWiki objects are stored as separate files, but binary file uploads are omitted.
• Real‑time collaboration (e.g. VisualEditor’s CollabPad) is not covered – you still need to push/pull to share changes.

Putting it all together

1. Install git‑remote‑mediawiki.
2. Clone the wiki: git clone git-remote-mediawiki::https://example.org/wiki my-wiki.
3. Work on pages locally, using branches for each feature.
4. Commit often, squash before merging, and push to a shared remote for review.
5. When the review is approved, push to origin master – the changes appear instantly on the live wiki.

With this workflow you get the best of both worlds: MediaWiki’s built‑in page history for on‑site users, and Git’s powerful branching, offline editing and code‑review tooling for developers.

Further reading

• Git‑remote‑mediawiki documentation
• VisualEditor real‑time collaboration (experimental)