Question

我创建了一个Git存储区，该存储区将专门存储在本地，我问自己，我是否真的需要Git LFS来存储二进制文件？据我所知，.gitattributes的配置如下：

*.psd binary

是的，文件位于.git/objects/...中，但是它们已压缩并且占用的空间不大。综上所述，如果我从不向/从远程仓库推送/拉取，那么本地存储库中的Git LFS有什么好处？

谢谢！

Answer 1

尽管Git提交是存储库内容的完整“快照”，但实际上并没有再次存储文件。 Git将文件的内容存储为由内容校验和标识的“ blob对象”；只有内容，文件名和权限才存储在树对象中。如果您对文件进行更改，则Git会将整个文件再次存储（压缩）为新的Blob。任何未更改的文件都将重用现有的Blob。而且，如果您有两个内容相同的文件，它们将共享相同的Blob。

在没有git-lfs的情况下，每次将更改提交到二进制文件时，都必须将整个文件（压缩的）再次存储在新的blob中。由于Git存储库是项目的完整历史记录，因此过一会儿可能会占用大量磁盘空间。如果空间狭窄，那对您可能很重要。

幸运的是，您现在不必做出此决定。如果存储库太大，则始终可以retroactively apply git-lfs later using the BFG Repo Cleaner。

Answer 2

要添加到@Schwern已经提供的出色答案中并解决OP的评论。

这是atlassian（支持此扩展的公司）的GIT LFS文档的link。

这个想法是二进制文件从“远程”存储库懒惰地下载，即在结帐过程中而不是在克隆或获取过程中。

从技术上讲git lfs存储“懒惰”的二进制评估指针。

这很有道理，因为git有一个“承诺”，可以在每次提交后为您提供对代码库状态的访问，因此可能出现以下情况：

提交A：添加了大型二进制文件a.bin（假设a.bin在版本1中）
推送更改
提交B：在二进制文件a.bin中进行了更改（a.bin现在处于版本2中）
推送更改
现在检出提交A的SHA1-git必须在版本1中为您提供a.bin。

这是正确的，即使您决定删除a.bin并提交它，在“ commit A”之后仍然应该可以访问文件系统状态。因此，如果您明确不需要版本1，那么至少在本地是没有意义的。

还有一个注意事项，直接解决这个问题并进行澄清：是的，您必须在本地启用git lfs支持，但除此之外，您还必须在远程仓库上启用git lfs支持（我曾经用bit bucket做到这一点，我肯定它的竞争对手也支持这一点。

Answer 3

这取决于您的工作流程和您可以访问的设施。

Git 将文件版本存储为 blob。这些 blob 是差异压缩的，因此仅存储差异。因此，文件大小仅略微增加。

如果版本化文件是二进制文件或单个更改即可重构整个文件的文件，则情况会有所不同。在这种情况下，Git 会存储每个文件的副本，从而使存储库快速增长。

Git 和 Git-LFS blob 大小的比较

Git 在差异压缩甚至大文件方面做得很好。我发现大文件的压缩效果非常好（大小完全变化）：

<头>

类型	改变	文件	作为 git blob	在 git gc 之后	作为 git-lfs blob
Vectorworks (.vwx)	添加几何体	28,8 MB	+26,5 MB	+1,8 MB	+26,5 MB
地理包 (.gpkg)	添加几何体	16,9 MB	+3,7 MB	+3,5 MB	+16,9 MB
亲和照片 (.afphoto)	切换层	85,8 MB	+85,6 MB	+0,8 MB	+85,6 MB
FormZ (.fmz)	添加几何体	66,3 MB	+66,3 MB	+66,3 MB	+66,3 MB
Photoshop (.psd)	切换层	25,8 MB	+15,8 MB	+15,4 MB	+25,8 MB
电影（mp4）	修剪	13,1 MB	+13,2 MB	+0 MB	+13,1 MB
删除文件		-13,1 MB	+0 MB	+0 MB	+0 MB

如果你没有远程推送，最好不要使用 Git-LFS，因为 Git-LFS 版本化文件似乎根本没有添加额外的压缩（见上文） .

另外一个重要的教训是，Git 的差异压缩方法不适用于 .fmz 等真正的二进制文件。这些将是置于 Git-LFS 版本控制之下的最佳候选者。

对于其他看似非文本但其结构类似于文本的文件类型（.vwx 或 .afphoto），diff 方法表现良好。在单用户场景中，总体存储库大小而不是提交速度很重要，我不会将它们置于 Git-LFS 版本控制之下，因为 Git blob 大小明显小于 LFS blob，从而节省了本地和远程空间.

Git-LFS 的好处

Git-LFS 通过将旧版本的大型二进制文件存储在存储库之外（远程）的位置并用指针文件替换它，从而为该问题提供了解决方案。如果需要旧版本，则客户端从远程拉取它。因此，如果设计者从遥控器拉取最新状态，他只会下载最新状态和指针文件。

因此，只有当您有权访问位于启用 LFS 的服务器上的远程时，才能促进 Git-LFS。如果没有服务器可以推送 blob，那么 LFS 跟踪的 blob 将保留在本地存储库中，因此不会利用减少本地存储消耗的优势。

通常，远程是启用 LFS 的 git 提供程序，这对于某些项目来说可能过于昂贵。但是，也有一些解决方案可以在本地托管 Git-LFS 远程。

如何在本地仓库中集成 Git-LFS

在本地，Git-LFS 仅允许通过 HTTP 传输数据。因此，您需要一个单独的 Git-LFS 服务器来存储大文件。但是，本地托管“没有官方服务器”implementation。但是有一些 unofficial 方式，例如 Git-LFS Folderstore 可以做到这一点。

Git-LFS Folderstore 提供了一种在本地管理 Git-LFS 远程的方法。它适用于本地机器和网络驱动器。如果您使用的是 Mac OS X，则可以通过将 lfs-folderstore 可执行文件 lfs-folderstore 复制到 /usr/local/bin 然后进行设置：

# Creating a remote repository on a volume (attached drive or NAS)
cd path/to/remote
mkdir origin

# create a bare git repository in origin
git init origin --bare

# Add remote to local repository
cd path/to/local/repository
git remote add origin <path/to/remote/origin>

# Enable Git-LFS
git lfs install

# Track filetype psd
git lfs track "*.psd"

# Configure lfs of the local repository
git config --add lfs.customtransfer.lfs-folder.path lfs-folderstore
git config --add lfs.standalonetransferagent lfs-folder
git config --add lfs.customtransfer.lfs-folder.args "Volumes/path/to/remote/origin"

# Commit changes
git commit -am "commit message"

# Push media to remote
`git push origin master`

如果您的远程路径包含空格，请使用 "'。

如何清理本地仓库

您可以通过调用 Git 垃圾收集器 git gc 来压缩 git 存储库的大小。它不会触及 Git-LFS 的 blob。

Git-LFS 只会从本地存储库 .git/lfs/objects/ 中删除 blob，前提是它们已被推送到远程并且如果包含 blob 的提交早于最近（3 天）。如果您想手动执行此操作，请使用以下命令：

# remove lfs duplicates
# https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-dedup.1.ronn
git lfs dedup

# clean old local lfs files (>3 days of commit)
# https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-prune.1.ronn
git lfs prune

我需要本地仓库的Git LFS吗？

3 个答案:

Git 和 Git-LFS blob 大小的比较

Git-LFS 的好处

如何在本地仓库中集成 Git-LFS

如何清理本地仓库