当大文件没有变化时，Git LFS的优势是什么？

Question

我考虑将Git LFS用于包含我们的系统映像构建工具（在本例中为Packer）使用的ISO和安装程序文件的存储库。然后我们将其添加为主仓库的子模块，该子模块具有构建脚本，因此可以将其集成到CI工具链中。

据我了解Git LFS，大文件被指针替换，因此repo拉动和维护很快，然后通过不同的通道下载文件。

但是，当我们添加文件时，他们会在名称中包含版本号，因此不需要更新（例如ubuntu-16.04.4-server-amd64.iso）。他们也不需要被删除，因为我们将在构建脚本中以该全名引用特定版本。我们基本上总是在添加，很少（如果有的话）更新或删除。

似乎Git LFS主要用于更新/删除。我们的用例是否还有其他技术优势？

Answer 1

只能从git lfs下载分支中使用的当前文件。来自其他分支机构或过去提交的文件将不会被下载。

如果您将所有内容放入标准git repo中，则始终会克隆所有内容，包括历史记录中中已删除的大文件。

因此，git lfs将允许您更快地在构建服务器上工作，因为克隆和下载所需的时间更短。

Answer 2

  

看起来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 gig的存储库来处理一些文本文件。

  

我们的用例是否还有其他技术优势？

是。使用git-lfs的成本很低。如果你早点而不是晚点使用它，那么成本最低。

您可以稍后使用git-lfs，但附加了一些字符串。如果您在现有文件上使用它们，它们将继续git-lfs，但它们的旧版本仍将保留在历史记录中。您可以use the BFG to rewrite history to retroactively put existing large files into git-lfs，但重写您的整个历史记录并不是您想要经常做的事情。您应该尽快使用git-lfs。

Here is a good run-down about what it takes to switch over later

早期使用git-lfs意味着开发人员不必考虑是否将某些东西放入存储库只是因为它太大了。如果他们认为应该在版本控制中，他们会将其置于版本控制中，无论大小如何。这简化了开发人员的决策制定流程，并创建了一个更健康的存储库。例如，如果您需要在存储库中有六个不同的操作系统ISO进行测试，他们可以在没有关于存储库膨胀的争论的情况下做到这一点。

这也意味着您不必为解决存储库膨胀问题而进行解决。有各种方法可以只克隆存储库的一部分，但它们都增加了复杂性。有办法让Git更有效地存储压缩的ISO和档案，你解压缩它们并让Git将它们存储为普通文件，但这又增加了复杂性。 git-lfs意味着你可以保持简单（r）。

最后，git-lfs的存储方面很灵活。你不会被Github或任何特定的Git网站用于LFS存储。

Answer 3

我认为这也是一种简单的方法，可以在不依赖其他工具的情况下始终确保这些依赖项可用。