我应该将git-lfs用于软件包信息文件吗？
作为使用几种语言的开发人员，我注意到在大多数现代语言中，依赖项元数据文件可能会发生很多变化。
例如，在nodejs中（我认为这是包裹管理的最糟糕的），依赖关系的更改或NPM（分别纱线）版本的版本可能会导致package> package> package lock.json的巨大变化。（分别yarn.lock），有时具有数万个修改线。
例如，在Golang中，这将是go.sum，当修改依赖项或运行GO MOD MOD TIDY AT时，它可能具有重要的更改（当然与节点相比，相比之下）会有重要的更改（与节点相比）。时代。
使用git-lfs跟踪这些依赖项文件会更有效吗？有理由不这样做吗？
即使它们是文本文件，我也知道建议使用git-lfs推动SVG文件，因为它们主要是生成的文件，并且它们的diff在更改后将其再生时没有理由很小。
是否有关于使git-lfs盈利的项目的语言和什么规模/年龄的研究？
As a developer working with several languages, I notice that in most modern languages, dependencies metadata files can change a lot.
For instance, in NodeJS (which in my opinion is the worst when it comes to package management), a change of dependencies or in the version of NPM (respectively yarn) version can lead to huge changes in package-lock.json (respectively yarn.lock), sometimes with tens of thousands of modified lines.
In Golang for instance, this would be go.sum which can have important changes (in smaller magnitude when compared to Node of course) when modifying dependencies or running go mod tidy at times.
Would it be more efficient to track these dependencies files with git-lfs? Is there a reason not to do it?
Even if they are text files, I know that it is advised to push SVG files with git-lfs, because they are mostly generated files and their diff has no reason to be small when regenerating them after a change.
Are there studies about what language and what size/age of a project that makes git-lfs become profitable?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
Git在压缩文本文件方面做得很好，因此最初，您可能不会看到太多收益。如果文件经常进行大量修改，那么随着时间的推移，如果您使用Git LFS，则可以将总可克隆回购大小增加更少，但是与总回购尺寸增加相比，这可能是不值得的百分比。 LFS的主要用例是经常更改的大量二进制文件。
如果您尚未使用Git LFS，我不建议出于这个原因开始。另外，尽管存在解决方法，但AFAIK并没有对存储在LFS中的文件的扩散版本的支持。如果您经常发现自己正在考虑正在考虑转移到LFS中的文件，则标称存储尺寸增益可能不值得。
Git does a pretty good job at compressing text files, so initially you probably wouldn't see much gains. If the file gets heavily modified often, then over time the total cloneable repo size would increase by less if you use Git LFS, but it may not be worth it compared to the total repo size increases, which could make the size savings negligible as a percentage. The primary use case for LFS is largish binary files that change often.
If you aren't already using Git LFS, I wouldn't recommend starting for this reason. Also, AFAIK there isn't native built in support for diffing versions of files stored in LFS, though workarounds exist. If you often find yourself diffing the files you are considering moving into LFS, the nominal storage size gain may not be worth it.