Artifacts 将工作存储在存储库中。存储库是一个隔离的 Git 服务，具有自己的历史记录、引用（ref）、远程 URL、令牌和持久状态。
每个存储库都位于一个命名空间内。如果命名空间尚不存在，则当您在其中创建第一个存储库时，Artifacts 会创建该命名空间。
命名空间对相关存储库进行分组，存储库名称在此分组中标识一个存储库。
存储库具有三个标识符：
- 命名空间名称
- 存储库名称
- API 返回的存储库 ID
命名空间和存储库名称构成了您在 Workers 绑定（binding）以及 REST API 和 Git 远程端中使用的稳定地址。当您在 API 响应或日志中需要不透明的标识符时，可以使用存储库 ID。
每个存储库都与其他存储库隔离。令牌、生命周期、引用（ref）和更改仅适用于该存储库。
Artifacts 通过三个接口暴露同一个存储库：
| 接口 | 用途 | 返回内容 |
|---|---|---|
| Workers 绑定（binding） | 从 Worker 创建、列出、导入、检查、分叉、删除以及生成令牌 | 存储库元数据、存储库句柄和存储库范围内的令牌结果 |
| REST API | 从外部系统创建、列出、导入、检查、分叉、删除以及生成令牌 | 包含存储库元数据和令牌结果的 Cloudflare API 响应 |
| Git 协议 | 克隆、拉取（fetch）、下拉（pull）和推送存储库内容 | 基于 HTTPS 的标准 Git 行为 |
这些接口指向同一个存储库。
例如，您可以从 Workers 绑定（binding） 或 REST API 创建一个存储库，然后将返回的 remote URL 递给标准 Git 客户端。您无需为每个接口创建不同的存储库。
Workers 绑定（binding）和 REST API 是控制平面接口。使用它们来管理存储库和令牌。
Git 协议是数据平面接口。使用它通过正常的 Git 工作流读取和写入提交、树（tree）和引用（ref）。
这种划分引出了一种通用模式：
- 使用 Workers 绑定（binding）或 REST API 创建存储库。
- 读取存储库的
remoteURL。 - 生成在存储库范围内生效的令牌。
- 将
remote和令牌与git clone、git fetch、git pull或git push一起使用。
存储库范围在两个方面起作用：命名和访问。
存储库名称在命名空间内是唯一的，而不是在您的整个账户中唯一。如果对您的环境或租户布局有帮助，您可以在不同的命名空间中重复使用简短的存储库名称。
例如，名为 app 的存储库可以同时存在于 prod 命名空间和 staging 命名空间中。
Artifacts 令牌是在存储库范围内生效的。为某个存储库生成的令牌不会授予对另一个存储库的访问权限，即使这两个存储库位于同一个命名空间中也是如此。
克隆、拉取（fetch）和下拉（pull）时使用 read 令牌。仅当客户端必须推送（push）更改时才使用 write 令牌。
当您将每个存储库视为一个工作单元时，Artifacts 的效果最好。
当这些单元需要独立的历史记录、清理和访问控制时，请为每个智能体、会话、用户任务、基线或分叉目标使用一个存储库。使用命名空间按环境、租户或分片（shard）对这些存储库进行分组。
有关更多信息，请参阅 命名空间、Artifacts 工作原理 和 Artifacts 最佳实践。