I’m fascinated with the idea of git not just as a version control system for source code, but a redundant, version controlled filesystem for anything.
Take git-wiki for example. It uses plain text Textile/Markdown files in a git repository as its database. You get all the benefits git users have for source code, but for wiki content. I’ve written a little scenario demonstrating some of the strengths of the platform.
Just by using git, you get:- version control: with past revision rollbacks, diffs, the whole lot
- redundancy: you can push up your entire wiki, with all changeset history, in seconds to multiple locations for backup
- security: since each blob is referenced by a cryptographically-secure SHA1 hash, as is each commit, you can be sure your wiki hasn’t been tampered with
- offline access: you can pull your entire wiki, again with all changeset history, to edit and interact with offline
- branching: make radical changes without affecting the mainline
The concept seems to apply well to a wiki, but I think they’d work as well in a CMS. Imagine being able to pull down an entire site’s content, create an experimental branch of content, refine it, then push it back up to your site: all while having the freedom to go back to any point in time in seconds.
The CMS backend (if there even is one) would still allow you to make changes online, but would check them in the git repository to be tracked. Stylesheets, images, original assets, and so on could be versioned along with the text, since git is so efficient even with binary files.
