我正在考虑使用 Git LFS 作为存储库，该存储库将包含我们的系统映像构建工具（在本例中为 Packer）使用的 ISO 和安装程序文件。然后，我们将其添加为具有构建脚本的主存储库的子模块，以便将其集成到我们的 CI 工具链中。
据我了解 Git LFS，大文件被指针替换，因此存储库拉取和维护很快，然后通过不同的渠道下载文件。
但是，当我们添加文件时，它们的名称中将包含版本号，因此它们不需要更新（例如ubuntu-16.04.4-server-amd64.iso）。它们也不需要删除，因为我们将在构建脚本中通过该全名引用特定版本。我们基本上总是会添加并且很少（如果有的话）更新或删除。
看来Git LFS主要是为了更新/删除。我们的用例还有其他技术优势吗？
看来Git LFS主要是为了更新/删除。
Git-LFS 主要是为了缩小存储库的大小。git clone通常会下载整个存储库，因此git-lfs主要影响clone. 该存储库包含所有文件和这些文件的所有版本，包括已删除的文件。
如果您对 Ubuntu 进行了较小的更新，并且git rm ubuntu-16.04.4-server-amd64.iso现在git add ubuntu-16.04.5-server-amd64.iso您存储了两个 ISO。另一个更新是三个。然后是四个。五。六。如果没有git-lfs，每个人都必须下载并存储所有那些旧的已删除 ISO。
如果您要存储大型文件（例如操作系统 ISO 或媒体文件），它们将迅速增大存储库的大小。这意味着任何克隆您的存储库的人都必须花费时间和带宽来下载所有内容，并在所有内容上花费磁盘空间。这会使您的开发过程变得臃肿，并使人们犹豫是否要下载一个 20 GB 的存储库来处理几个文本文件。
我们的用例还有其他技术优势吗？
是的。使用 的成本很低git-lfs。如果您尽早使用它，那么成本是最低的。
您可以git-lfs稍后使用，但有一些附加条件。如果您在现有文件上使用它，它们将继续存在git-lfs，但它们的旧版本仍将留在历史中。您可以使用 BFG 重写历史记录，以追溯地将现有的大文件放入 中git-lfs，但重写整个历史记录并不是您经常想要做的事情。您可能应该git-lfs尽早使用。
尽早使用git-lfs意味着开发人员不必因为某些内容太大而苦苦思考是否将其放入存储库中。如果他们认为有些东西应该纳入版本控制，他们就会将其放入版本控制中，无论大小如何。这简化了开发人员的决策过程，并建立了更健康的存储库。比如说，如果您需要在存储库中有六个不同的操作系统 ISO 进行测试，他们可以做到这一点，而无需担心存储库膨胀。
这也意味着您不必采取变通措施来解决存储库膨胀的问题。有多种方法可以仅克隆存储库的一部分，但它们都会增加复杂性。有一些方法可以让 Git 更有效地存储压缩的 ISO 和存档，您可以将它们解压并让 Git 将它们存储为普通文件，但这又增加了复杂性。git-lfs意味着你可以让事情变得简单（r）。
最后，存储方面git-lfs是灵活的。您无需依赖 Github 或任何特定的用于 LFS 存储的 Git 站点。