Suggestions for tracking a MediaWiki wiki with Git version control?

Question

In my research I found that there seems to be no "single source of truth" for where to post MediaWiki questions. MediaWiki questions have been posted on these many Stack Exchange network subdomains:

ProWebmasters, Security, Web Applications, Software Recommendations, (and probably others).

So, I'm taking a shot and posting my question here, because the question is about hosting mediawiki sites and software best practices.

MY Question

1a) What is considered best practice in 2021 for how to put a mediawiki site under Git version control? I tried CD into mediawiki folder and type git init. But, it gives me umpteen warnings about CRLF line endings. I understand that it has to do with auto converting from Linux line endings to Windows and vice versa. I chose to set autocrlf to true, as is recommended by many sources.

But, then I just get all these warning messages. So, I found a video on how to suppress the warning messages with .gitattributes file, which worked, but __it didn't shorten the length of time to finish git add of all the files and folders in MediaWiki. At present, I have deleted the .gitattributes file since I at least now I will know that Git is still processing (by the warning messages) and not just stuck or hung on a process.

1b) After deleting the .gitattributes file the git add process seemed to finish even quicker! Upon completion of git add, I see all these "create mode 100644" messages. I don't know if I should be worried about them or not. What does create mode 100644 mean and should I be worried about that at all?

1c) The last part of my question is simply this. If I were to say I was going to put 100 GB of video and zip files under git source control many of you would rightly advise "Don't do it, bro!", because although you can do it, it is not a good idea. Based on how long it took just to do the git add command, I'm wondering if putting mediawiki under git is even a good idea. I want to edit files in my mediawiki install, track the edits, be able to revert them when necessary, experiment on other branches, etc.Therefore,

Is it even recommended or not a good idea to put installations of framework-based websites like MediaWiki, WordPress, etc. under git source control? Or are the perhaps special considerations that one must know to do it safely/correctly/best-practice-ly?

Answer 1

It's a good impulse, what you're trying to do. You just need to scale back your expectations about what all gets tracked by Git.

Because LocalSettings.php is the main thing, you definitely want to track that, especially between upgrades and installing new extensions. I tweak that thing constantly, so being to run git diff or git log on it is invaluable.

Apart from that, your images folder, and the actual contents of your database, everything else is so transitory, it's probably not worth putting in version control. Most of it will be obliterated the next time you upgrade MediaWiki anyway.

In a local Git repository (not git pushed to any external host), I track the config file, Composer configs, any icons or logos I create that are referenced from the site's CSS, plus any patches against third-party extensions. I put those latter things in a local subdirectory. I download and unpack third-party extensions into local/extensions.

Here is my .gitignore:

# ignore everything by default
*

# except add these
!Makefile
!LocalSettings.php
!*.diff
!composer.json
!composer.local.json
!composer.local.lock
!composer.lock

!local
!local/diffs
!local/diffs/.htaccess
!local/icons
!local/icons/**
!local/logo
!local/logo/**

Remember that LocalSettings.php probably has your database password in it. If you were intending to push your config to some external Git hosting service like GitHub, 1) maybe reconsider that; or 2) put the password in an external file, excluded from version control, and read that in. In my case, I just chmod 700 or chmod 770 the LocalSettings.php and leave the Git repo local to the server, where it gets picked up by nightly backups.

I have a "deny all" rule for .git directories in the top-level web server config; that's also something you should be cautious about.

This is probably beyond the scope, but Makefile named in the .gitignore above creates symlinks for all the directories in local/extensions into extensions and local/skins → skins.

Here's the relevant part:

SHELL = bash

# create symlinks for local/* into the usual places
links: local-extensions local-skins

# link locally-installed extensions into the 'extensions' dir
local-extensions:
    $(call link-local,extensions)

# link locally-installed skins into the 'skins' dir
local-skins:
    $(call link-local,skins)


define link-local
    @cd "$(1)"; \
    while read dir; do \
        basename=$$(basename "$$dir"); \
        if [[ -L $$basename ]]; then \
            echo "(ii) Link for '$(1)/$$basename' already exists. Skipping." >&2; \
            continue; \
        fi; \
        ln -s "$$(realpath --relative-to=. "$$dir")"; \
        echo "(++) Added '$(1)/$$basename'." >&2; \
    done < <(find "$(PWD)/local/$(1)" -mindepth 1 -maxdepth 1 -type d)
endef

By confining the skins and extensions that I added to the local subdirectory and creating symlinks, MediaWiki upgrades are way easier for me, because it's clear where the "factory" stuff ends and my local customizations begin.

Hope that helps!

Answer 2

Neither MediaWiki nor WordPress lend themselves to having an entire site put under git version control. There are several reasons for this:

1. Sites often have large amounts of uploaded binary image files. Git is best at tracking text changes and won't do a good job as a store for images.
2. The text content of these sites is stored in a database. The database uses a binary format to store all its data. So even the text content of these sites is not readily able to be managed by git. At best you would have to dump the database to SQL to commit it to git.
3. Changes to the sites can be made directly on the site itself and the site software has no hooks to check these changes into git. Git version control works best when everything that modifies the content knows to check changes into git.
4. The code that powers sites is usually installed from a downloaded zip file rather than from git. You would also have to download code updates and check them into git.

It isn't clear what you would gain by checking these entire sites into git. MediaWiki has change tracking for edits built into it already, so you shouldn't need git to show you history of each page. Both MediaWiki and WordPress can be (and should be) backed up without using git.

If you are making changes to code that powers a site, it would make sense to use git for that code. For example if you were developing a WordPress theme you would want to check your theme into git, but you wouldn't want to check your entire site into git.