基于 Git 的内容管理？ [关闭]

Posted 2023-02-22

【中文标题】基于 Git 的内容管理？ [关闭]

【英文标题】：Git-based content management? [closed]

【发布时间】：2011-07-19 03:32:03

【问题描述】：

我正在寻找可以提供和编辑位于 Git 存储库中的内容的 Ruby CMS（或插件）。我厌倦了将我的内容放在数据库中。用户，设置，cmets，很好。但没有更多内容了。

对页面的每次实时编辑都需要自动立即提交，以防止需要进行服务器端合并。此外，无论何时推送新的更改，都需要立即在文件系统上进行更新。

Refinery CMS 文档似乎做了类似的事情，尽管可能使用远程存储库。

我已经阅读了有关 GitModel 和 git-blog 的信息，但我仍在寻找更符合我需求的东西。 [编辑：与大多数 CMS 一起使用时，GitModel 很难手动编辑，而 git-blog 使用静态文件生成。]

编辑：我对内容数据库的偏见仅适用于需要高度自定义的网站，并且不能按原样使用任何 CMS。 代码与其内容一样多的网站。这是当在数据库中拥有内容是一场彻头彻尾的噩梦时。当您需要同时分叉内容和代码时，它们稍后会将它们合并到生产中。数据库不会分支和合并。

我有这样一个网站。

支持仅 DB 内容的性能论点是无效的。我 5 年前写了一个 CMS，它从文件系统同步数据库，其中文件系统始终是主副本。它可以轻松扩展到 100,000 个页面，保持 10 毫秒的响应时间和 2 秒的重新索引时间。所有内容、元数据、标签、日期等的完全可搜索索引。哎呀，我用地球上最慢、最痛苦的框架 ASP.NET 编写了它。实际上，它几乎使 ASP.NET 变得可以接受，并且它为各种公司提供了非常好的服务，因为它们拥有与上面提到的相同类型的网站。

小型网站可以简单地使用内存缓存，完全跳过数据库内容

仅 db 内容的一个有效参数是编辑的可扩展性。编辑者必须全部使用相同的服务器，但可以向外复制更改。但是对于快速变化、高度定制的网站，这些网站更改代码的频率与内容一样多，不太可能对所述代码和内容进行分布式/社区编辑。 社区/分布式编辑可以使用不同的系统。

到目前为止，我最接近的是使用 Cloud9 编辑内容的 git 存储库（Nesta CMS），然后通过命令行推送更改。它很慢，但至少它是基于网络的，以防我的开发机器不方便，我发现我在一篇文章中拼错了我的名字。仍在寻找更好的选择。

【问题讨论】：

您想谈谈为什么不希望数据库中有内容吗？

“我已经阅读了有关 GitModel 和 git-blog 的信息，但我仍在寻找更符合我需求的东西。”那些你觉得不满意的地方是什么？

GitModel 在文件的编写方式上没有提供很大的灵活性，并且直接编辑它们有点困难。 git-blog 使用静态生成，而我的大部分网站将包含高级动态功能。

在本地数据库和实时数据库之间同步更改始终是一场噩梦，即使使用自动批量复制的工具（例如 Heruk 的 db:push 和 db:pull）也是如此。当内容非常独立于应用程序时，例如在博客或 wiki 中，同步更改不是一个大问题。但是在开发 CSS 和代码交互并依赖于内容时，内容的版本需要与代码保持同步。

【参考方案1】：

Gollum (https://github.com/github/gollum) 是一个由 Git 驱动的 wiki，由 GitHub 在 Sinatra 中编写。您既可以从命令行推送和拉取，也可以使用随附的 Web 界面来编辑内容。

不幸的是，GitHub 似乎有些东西放弃了它的开发/维护，所以它有一些粗糙的边缘。它也是非常基础的，因此它不包含身份验证等功能[1]。

我将使用 Gollum 和 gollum-site (https://github.com/dreverri/gollum-site)，Gollum 的静态文件生成器，并且只使用 Gollum 作为管理后端。

1：身份验证的基本解决方案可以在https://github.com/github/gollum/issues/107#issuecomment-2608061找到

---

还有Regulate，https://github.com/quickleft/regulate：

提供 Git 支持的 CMS 的 Rails 3 引擎允许管理员在页面视图中定义可编辑区域。

【参考方案2】：

您的解决方案以后可能会太混乱，以后您可能会更头疼。

我的建议是：(1) 使用 NoSQL，例如 MongoDB。 (2) 从以前的数据库中迁移所有数据。 (3) 然后将您的数据库置于版本控制之下。可以，因为它是基于文档的，而不是 SQL。

Mongo 也有一个很棒的 Gem，叫做 MongoID https://github.com/mongoid/mongoid

这样您就可以使用拥有更大社区的 CMS（例如 Refinery）。此外：您的数据库备份很容易解决，因为您可以随时使用 Git 回滚或有时只是克隆您的数据库，您还可以自动备份等。

HTH

【参考方案3】：

也许你可以结合一个 git 包装器进行编辑等：

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

使用您自己的基于简单文件存储系统的渲染代码。

虽然我对 Ruby 不太熟悉，所以在 Ruby 渲染方面帮不上什么忙。

您发表的“我的大部分网站都将包含高级动态功能”的评论看起来您需要根据自己的独特要求推出自己的解决方案。

【参考方案4】：

我最终实现了一个micro-CMS called Hardwired，它在不妨碍我的方面做得很好。

试一试。

【参考方案5】：

您出于什么原因要将您的内容保存到 git 存储库中？究竟是什么问题让你如此讨厌数据库？ DBMS 是为快速数据读取和写入而构建的，而 git 是为变更管理而构建的。这是一种架构选择，您可能会因此而自取其辱。

如果问题在于覆盖条目的用户，那么您应该引入功能来归档以前的版本（或它们的差异）而不是覆盖它们。例如 rails_admin gem 就是这样做的

即使立即提交，您也不会逃避这样一个问题：一个用户打开一个条目进行编辑并保留一个小时直到他保存它，同时另一个用户在 5 分钟内进行快速编辑。在这里，您需要从客户端发送他正在编辑的修订版本，并且在发生冲突的情况下，显示一个界面，用户可以在其中将他的修订版本与其他用户所做的修订版本进行比较。或者，如果您很先进，那么您可以使用 google-docs 方式进行操作。启用同时编辑。

【讨论】：

我的网站是单编辑网站。保存时锁定就足够了。

另外，你可以让每个编辑器在他们自己的分支上工作，然后构建一个 git diff 和 merge 的接口来帮助合并更改。似乎社区都在武装起来，您认为神圣的 DBMS 可能并不总是最好的解决方案。我一个人说去吧。 Git 是一个对象数据库，在我看来，它为内容管理提供了很多优势。