我们使用内部部署Azure DevOps，并且刚刚开始试用Git LFS。我在git(由Visual Studio IIRC安装的2.31.1.windows.1(旁边安装了最新的客户端(3.0.2(，当从包含LFS文件的DevOps克隆git repo时，最初一切看起来都很好。
然而，我的本地repo只引用了LFS文件，当尝试运行git lfs pull(或fetch，或推送一个新的LFS跟踪文件(等命令时，我会遇到与http://<server>:8080/tfs/<collection>/<project>/_git/<repo>.git/info/lfs有关的身份验证错误，即git-reo URL的子路径。
谷歌搜索向其他人展示了类似的问题，但没有明确回答发生了什么，为什么，或者如何解决。我不明白这是DevOps实现问题，还是本地客户端问题。
我确实遇到过关于Git LFS不使用与Git相同的凭据或身份验证类型的讨论，或者可能在不同的地方寻找它们——请注意，我们使用的是HTTP而不是HTTPS，也许这是一个因素？
Git LFS使用了与Git中不同的HTTP和TLS库。Git使用libcurl，Git LFS使用Go HTTP库。因此，支持的身份验证逻辑不同，尽管两个程序都将使用Git凭据助手和其他凭据查找逻辑。
既然你提到Azure DevOps，我猜你在使用NTLM。在3.0中，Git LFS删除了NTLM，因为它有已知的错误，没有人对修复它们感兴趣，而且它使用了自1995年以来已知不安全的加密技术。Azure DevOps是已知的唯一使用NTLM的主要网站，Git LFS维护人员询问他们是否愿意参与帮助维护，但他们拒绝了。
NTLM可以通过以下两种方式之一进行处理：通过NTLM身份验证方案或Negotiate身份验证方案。后者也由Kerberos使用，Git和Git LFS都支持Kerberos，并且它是安全的。目前，如果NTLM设置为使用Negotiate，Git LFS根本无法工作，因为它优先考虑Negotiate而不是Basic。在即将发布的3.1中，预计本月或下个月发布，如果Negotiate失败，Git LFS将回落到Basic，因此即使在实例上启用了NTLM，您也可以工作。
我强烈鼓励大家放弃NTLM，因为它太不安全了。真的没有理由再使用它了：甚至微软告诉你关闭它。如果你在你的实例上关闭NTLM，或者切换到Kerberos，一切都应该正常。否则，您需要等待Git LFS 3.1，或者在配置中将身份验证方法显式设置为basic。