AFAIK Crafter CMS 3.0 版之前使用 Alfresco 作为存储库，而后者又使用 RDBMS 数据库作为存储元数据的底层数据库。它说 Crafter CMS 3.0 使用 git 作为存储库。
我的应用程序将涉及大量图像文件以及元数据，我假设图像文件存储在文件系统中，元数据存储在 Crafter CMS 3.0 的底层数据库中。
还有没有什么特别的原因，crafter CMS 3.0 选择不使用 JCR/Jackrabbit 作为 Magnolia 和 Hippo CMS 正在做的存储库？
Crafter CMS 是一个解耦的 CMS，这意味着有一个独立的创作系统和交付系统。在 Crafter CMS 的情况下，它们分别是 Crafter Studio 和 Crafter Engine。
在 2.5 版之前（包括版本），Crafter Studio 使用 Alfresco ECM 作为其主要内容存储库，正如您正确指出的那样，从 3.0 版开始，Git 成为持久性存储库。Crafter Engine 始终使用文件系统，从不依赖 RDBMS 或 ECM。Solr 用于搜索，Solr 在创作和交付中运行，内容通过 Crafter Deployer 在那里建立索引。
值得注意的是，除了 Git，Crafter Studio 3.0 确实使用小型嵌入式 RDBMS 模式 (MariaDB) 来维护对象状态和其他与 CMS 相关的活动。但是，如果需要，可以根据 Git 状态重建该数据库。
关于基于图像和视频的应用程序：最佳实践是在 Crafter 中对这些资产进行建模，但依赖于外部存储（如 S3、Box、通过 CMIS 的 Alfresco——所有这些都是本机支持的，但所有这些都是可选）用于二进制文件，但将元数据保留在 Crafter CMS 中。这意味着内容元数据在 Crafter Engine 中可用（通过 Groovy、FreeMarker 或 Java，通过加载描述符 (XML) 或查询 Solr），并且可以根据交付需要对二进制文件进行转换、转码。
话虽如此，如果您愿意，您仍然可以将您的内容对象（XML + 二进制）直接存储到 Git 中。
因此，为了尝试在更高层次上回答您的问题：Crafter CMS 使用 XML 来存储内容和元数据，该 XML 可以指向二进制资产（创建关联）。XML 以图形方式建模以生成表单，表单呈现为内容的叠加层，供内容作者创建内容并最终在 Git 中生成 XML。XML 由 Solr 通过 Crafter Deployer 编制索引（在创作和交付中运行），并且可供 Crafter Engine 使用（因此您的应用程序是用 Groovy 和 FreeMarker（如果您真的需要，也可以使用 Java）编写的）。
不使用 JCR 的原因太多，无法在此处列出——Git 提供了更好的开发人员工作流程、性能、可扩展性、devops 支持等。请参阅 Crafter Software 网站上的#NoJCR 录制的网络研讨会，其中涵盖了一些推理。另一个即时资源是拱形概述：http ://docs.craftercms.org/en/3.0/developers/architecture.html