DVC并不比git-lfs好：它们是完全不同的。选择的答案在很大程度上是有偏见的。两者只是不同的工具，用于不同的目的。

*git-lfs的目的是对git透明，因此它需要一个自定义的服务器。它的学习过程短而快。一些配置命令，砰！它正在运行，独立于git仓库存储大文件。这是它唯一的功能，它做得很好。拥有一个额外的服务器不是一个缺点，而是这种透明性的要求。一旦配置好，文件只是由git通过git钩子（git操作后激活的端点）来处理。
*DVC旨在为最终用户提供对大文件的独立管理，DVC基本上做的是这样的：它只会让git忽略你想要控制的文件（添加到.gitignore），而生成一个扩展名为.dvc的同名文件。因此，为了推送一个包含相应文件的提交，用户需要手动“add”（相当于 git commit，而不是 git add;在dvc中没有git stage的等价物）和“push”到两个系统。这不是缺点，而是必要的控制级别。作为交换，远程大文件保持器只是任何远程文件系统，可以通过它的路径直接访问，通过ssh或通过多个驱动程序（google drive，amazon等）。无论如何，钩子也可以用于dvc，这将简化大文件的使用，如果拥有额外的文件并不令人烦恼，并且将文件保存到远程设备需要额外的操作，请记住它们是.gitignored！因此，如果您修改了存储在dvc中的文件，git status将不会注意到这样的更改，并且您可能会丢失这样的更改，除非您使用dvc进行额外的检查。
DVC的用途与git-lfs不同。DVC不仅用于保存大文件，而且主要 * 用于管理确定性进程产生的大文件 *。因此，除了存储大文件之外，dvc还像Makefile一样，通过在Makefile中定义依赖关系来控制处理管道。并且如果处理输入（也是由DVC跟踪的文件或参数）改变时，DVC计算必须重新生成哪些文件（是的，就像Makefile s）。这就是为什么DVC通常被描述为 * 数据科学的makefile工具 *。如果你正在生成大型AI模型或大量数据文件，这很酷。与编译大型应用程序完全相同：每一个局部变化都意味着仅仅编译整体的一小部分。

就我个人而言，我使用这两种方式来存储大文件。git-lfs简化了大文件的管理（典型情况：构建一个AI Docker容器，里面有一个大的模型文件，同时有一个小的git repo，几乎没有git知识，而dvc需要一些），但dvc简化了大文件的存储（这简化了管理，例如，我可以很容易地在DVC存储库中找到并删除我不想要的文件，而git-lfs不能/它很复杂），代价是没有这样的透明性，有时会丢失数据。我仍然不使用dvc进行流水线计算，直到现在我更喜欢自己的实现。DVC越来越好，也许我将来会更多地使用它。两者只是不同;根据用途，我目前两种都用。

DVC是git-lfs更好的替代品。
与git-lfs不同，DVC不需要安装专用服务器;它可以在本地使用（例如NAS、SSH），也可以与任何主要的云提供商（S3、Google Cloud、Azure）配合使用。
如需了解更多信息：https://dvc.org/doc/use-cases/data-and-model-files-versioning