Git-based content management? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.

---

Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.

Closed 8 years ago.

开发者_运维百科 Improve this question

I'm looking for a Ruby CMS (or plugin) that can serve and edit content located in a Git repository. I'm sick of having my content in a db. Users, settings, comments, fine. But no more content.

Each live edit to a page will need to be automatically, immediately committed to prevent the need for server-side merging. Also, whenever new changes are pushed, they will need to be immediately updated on the filesystem.

Refinery CMS documentation seems to do something similar, although perhaps with a remote repository.

I've read about GitModel and git-blog, but I'm still looking for something that matches my needs a bit closer. [EDIT: GitModel is too hard to edit by hand when used with most CMSes, and git-blog uses static file generation.]

EDIT: My bias against databases for content only applies to sites that need a high degree of customization, and can't use any CMS as-is. Sites whose code evolves as much as its content. This is when the having content in a DB is an utter nightmare. When you need to fork the content and code at the same time, them merge them both into production later. DBs don't branch and merge.

I have such a site.

The performance argument in favor of DB-only content is null and void. I wrote a CMS 5 years ago that synchronizes the database from the filesystem, where the filesystem is always the master copy. It scaled easily to 100,000 pages, maintaining 10ms response times and 2s reindex times. Fully searchable indexes of all the content, metadata, tags, dates, etc. And heck, I wrote it in the slowest, most painful framework on the planet, ASP.NET. It actually almost made ASP.NET bearable, and it has served various companies extremely well, since they had the same kind of site as mentioned above.

Small sites can simply use an in-memory cache, skipping the db content altogether

A valid argument for db-only content is scalability of editing. Editors must all use the same server, although changes can be replicated outward. But in the case of quick-changing, highly customized sites who change code as often as content, distributed/community editing of said code and content is unlikely. Community/distributed editing can use a different system.

So far, the closest I have come is using Cloud9 to edit a git repository of content (Nesta CMS), then push the changes via the command line. It's slow, but at least it's web-based in case my dev machine isn't handy which I discover I misspelled my name in an article. Still looking for better options.

---

Gollum (https://github.com/github/gollum) is a Git-powered wiki written by GitHub in Sinatra. You can both push and pull from command line or use the included web interface to edit content.

Unfortunately it seems like GitHub have some what abandon development/maintenance of it, so it has some rough edges. It's also very basic, so it does not include features such as authentication[1].

I'm gonna use Gollum with gollum-site (https://github.com/dreverri/gollum-site), a static file generator for Gollum, and just use Gollum as the admin backend.

1: A basic solution to authentication can be found at https://github.com/github/gollum/issues/107#issuecomment-2608061

---

There is also Regulate, https://github.com/quickleft/regulate:

Rails 3 engine that provides a Git backed CMS that allows for an admin to define editable regions in a page view.

---

Your solution might be too confusing later and you may have more headaches later.

I advice this: (1) Use a NoSQL such as MongoDB. (2) Migrate all your data from previous DB. (3) Then put your DB under versioning with. You can, since it's document-based and not SQL.

Mongo has an excellent Gem too, called MongoID https://github.com/mongoid/mongoid

This way you can use a CMS which has much bigger community (like Refinery). Further more: your DB backups solved easily becuase you are able to roll back anytime with Git or simply clone your DB sometimes, also you can automatize backups, etc.

HTH

---

Maybe you could combine a git wrapper for editing, etc:

https://github.com/schacon/ruby-git

with your own rendering code based on a simple file based storage system.

I'm not so familiar with Ruby though, so can't help much on the ruby rendering side of things.

This comment you make "most of my site will contain advanced dynamic functionality" looks like you are going to need to roll your own solution based on your unique requirements.

---

I ended up implementing a micro-CMS called Hardwired that does an excellent job of staying out of my way.

Give it a try.

---

For what reason do you want to keep your content into a git repository? What exactly is the problem that makes you hate databases so much? A DBMS is built for fast data reads and writes, whereas git is built for change management. This is an architectural choice with which you might shoot yourself in the foot.

If the problem lies in users that overwrite entries, then you should rather introduce functionality to archive previous versions (or the diff's of them) not overwrite them. For example the rails_admin gem does that

And even with immediate committing you will not escape the problem that one user opens an entry for editing and keeps it for an hour until he saves it, where at the same time another user does a quick edit in 5 minutes. Here you need to send from the client which revision has he been editing and in the case of conflict, show an interface where the user can compare his revisions with the ones made by the other user. Or if you're advanced then you can do it the google-docs way. enable simultaneous editing.