我应该对包信息文件使用 git-lfs 吗？

对于经常发生较大变化的依赖项元数据文件，例如 NodeJS 中的 package-lock.json 和 Golang 中的 go.sum，使用 Git LFS 进行跟踪是否有效值得商榷。虽然 Git 擅长压缩文本文件，但 Git LFS 主要适用于大型二进制文件。对于小规模文本文件，Git LFS 的收益可能很小，并且与 Git LFS 相关的存储空间增加可能会抵消节省的大小。此外，Git LFS 对文件差异版本缺乏本机支持，这可能会影响比较存储在 LFS 中的文件。

作为使用多种语言的开发人员，我注意到在大多数现代语言中，依赖项元数据文件可能会发生很大变化。

例如，在 NodeJS 中（在我看来，在包管理方面这是最糟糕的），依赖项或 NPM（分别是yarn）版本的更改可能会导致 package-lock.json 发生巨大变化（分别为 yarn.lock），有时有数万条修改行。

例如，在 Golang 中，这将是 go.sum，当修改依赖项或有时运行 go mod tidy 时，它可能会产生重要的变化（当然与 Node 相比，幅度较小）。

使用 git-lfs 跟踪这些依赖文件会更有效吗？有什么理由不这样做吗？

即使它们是文本文件，我知道建议使用 git-lfs 推送 SVG 文件，因为它们大多是生成的文件，并且在更改后重新生成它们时它们的差异没有理由很小。

是否有关于什么语言以及项目的规模/年龄可以使 git-lfs 盈利的研究？

正确答案

Git 在压缩文本文件方面做得非常好，因此最初您可能不会看到太多收益。如果文件经常被大量修改，那么随着时间的推移，如果您使用 Git LFS，可克隆存储库的总大小会增加得更少，但与存储库总大小的增加相比，这可能不值得，这可能会使节省的大小可以忽略不计，因为百分比。 LFS 的主要用例是经常更改的大型二进制文件。

如果您尚未使用 Git LFS，出于这个原因我不建议您开始使用。此外，据我所知，尽管存在解决方法，但对于存储在 LFS 中的文件的差异版本没有本机内置支持。如果您经常发现自己正在比较正在考虑移入 LFS 的文件，那么名义上的存储大小增益可能不值得。

到这里，我们也就讲完了《我应该对包信息文件使用 git-lfs 吗？》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！