thoughts on git-backed content management system

I’ve said elsewhere that the ideal content collaboration experience for most purposes is not a wiki with revision wars, and certainly isn’t a comment box or contact form, but instead a simple user interface to suggest changes by editing a copy of the content, backed by a distributed version control system (which, for better or worse, in 2018 means Git).

However, a single repository for a site is not a good model for most purposes. My initial mental model was simple: A Jekyll-style generated static site where there’s an ’edit to suggest changes’ link that takes a would-be contributor to a place comparable to GitHub or GitLab, but designed to make normal people (not programmers) comfortable. The problem with this is it requires the repository to be public (or for the platform to be centralized and locked down). There’s lots of reasons for draft posts or other posts to stay private until they’re published. So i’m wondering if a one-off spinoff of the content to be edited makes more sense. It presumably wouldn’t have the history of changes a full repository has. (Actually, there’s probably a way to do that but it would in effect make drafts retroactively public, which again we may well not want.) It also wouldn’t have the capacity for a related group of edits to multiple pieces of content be in one merge request, which (while not likely to be common) is a huge attraction for a git-based flow.

I think there are ways to make a shallow no-history clone of portions of a repository with Git. A ‘public-only’ history would be the ideal, but i’m less confident there’s any way to figure that with Git. (Or any other DVCS but i’d be happy to be proven wrong.) I’m not too sure of the ability to clone only portions of a repository either, but if it is possible it would likely require a way of marking posts as draft that’s more accessible to Git than in-content “metadata” such as the absence of publish: true or the presence of publish: false (or in Jekyll and Hugo style, draft: true). A change to the file name or extension ( or, say) might work; having drafts in a drafts folder (or subfolder if possible) almost certainly would work.


This concept has also been developed and given a name, “Content as Code”, by someone also publishing on with the same theme as i’m using, but despite all this evidence we are probably not the same person:

They are not interested in my hope above, allowing public viewing the source code and editing through the same git-backed workflow, but i do quite want that somehow.

One other person wants it with NextCloud as part of the stack:

See also: