Lib.rs

通过利用 Git 历史过滤的闪电般快速、增量且可逆的实现，将单仓库的优点与多仓库设置的优势相结合。

josh-proxy 可与任何基于 HTTP 的 Git 服务器集成

$ docker run -p 8000:8000 -e JOSH_REMOTE=https://github.com -v josh-vol:/data/git joshproject/josh-proxy:latest

用例

部分克隆

将单仓库的子目录视为单独的仓库，以减少克隆的范围和大小。

$ git clone http://josh/monorepo.git:/path/to/library.git

部分仓库将作为正常的 Git 仓库运行，但仅包含子目录中的文件和仅影响这些文件的提交。部分仓库支持拉取和推送操作。

这不仅可以减少树中的文件数量以提高客户端性能，还可以使其他使用 Git 的常规分布式开发功能的其他方能够与其他方协作单仓库的部分。例如，这使得镜像所选部分仓库到公共 GitHub 仓库或特定客户变得容易。

项目组合/工作区

简化代码共享和依赖关系管理。Josh 不仅支持子目录，还支持从单仓库中找到的内容的任意虚拟仓库的过滤、重新映射和组合。

映射本身也存储在仓库中，因此与代码一起版本化。

中心单仓库	项目工作区	workspace.josh 文件
		dependencies = :/modules:[ ::tools/ ::library1/ ]
		libs/library1 = :/modules/library1

工作区作为正常的 Git 仓库运行

$ git clone http://josh/central.git:workspace=workspaces/project1.git

简化 CI/CD

由于所有内容都存储在一个仓库中，CI/CD 系统只需要查看每个特定交付成果的一个源。然而，在传统的单仓库环境中，依赖关系管理由构建系统处理。构建系统通常是针对特定语言量身定制的，并且需要在文件系统中检出其输入。因此，以下问题

"受特定提交影响的交付成果是什么，需要重新构建？"

无法在没有克隆整个仓库并理解使用的语言如何处理依赖关系的情况下回答。

特别是当使用 C 家族语言时，对头文件的隐藏依赖很容易遗漏。因此，通过沙箱隔离将文件的可视性限制到编译器对于可重复构建几乎是必需的。

与Josh合作，每个可交付成果都会有一个虚拟的git仓库，其中依赖项在workspace.josh文件中声明。这意味着回答上述问题就像比较提交ID一样简单。此外，由于树过滤，每个构建都保证是完美沙盒化的，并且只能看到实际上已映射的单一代码仓库的部分。

这也意味着可以确定需要重新构建的可交付成果，而无需像使用常规构建工具那样克隆任何仓库。

GraphQL API

通常希望在不克隆仓库的情况下访问存储在git中的内容。这对于CI/CD系统或仪表板等Web前端非常有用。

Josh为此目的公开了一个GraphQL API。例如，它可以用来查找当前在树中存在的所有工作空间

query {
  rev(at:"refs/heads/master", filter:"::**/workspace.josh") {
    files { path }
  }
}

缓存代理

即使不使用诸如部分克隆或工作空间等更高级的功能，josh-proxy也可以作为缓存来减少地点之间的流量，或者防止您的CI对主git主机执行许多请求。

常见问题解答

请参阅这里