我有以下"伪"；访问存储库的凭据(用户名和PAT(：
bd6164:o6g5xae5fmqeqdbjatdfjichdk55lweq4jxyt2jvwtjuzxdwwgxa
现在，根据MS文档，我应该使用git -c http.extraHeader="Authorization: Basic <base64>" ...将这些凭据提供给git，这将导致成功的身份验证。
但是，如果我直接在URL:中将这些凭据提供给git
https://bd6164:o6g5xae5fmqeqdbjatdfjichdk55lweq4jxyt2jvwtjuzxdwwgxa@azuredevops.example.net
则验证失败。
通常，当我使用git时，我可以将我的凭据直接放在URL中以成功进行身份验证，那么为什么我会遇到这些不一致呢？一般来说，URL中的凭据不是转换为Base64并以"；授权：基本；HTTP标头？
以下是MS关于如何将PAT与git:一起使用的文档
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=预览页#use-a-pat
作品：
# git -c http.extraHeader="Authorization: Basic YmQ2MTY0Om82ZzV4YWU1Zm1xZXFkYmphdGRmamljaGRrNTVsd2VxNGp4eXQyanZ3dGp1enhkd3dneGE=" clone https://azuredevops.example.net/Main/MyProj/_git/MyRepo
失败：
# git clone https://bd6164:o6g5xae5fmqeqdbjatdfjichdk55lweq4jxyt2jvwtjuzxdwwgxa@azuredevops.example.net/Main/MyProj/_git/MyRepo
在Git 2.34(2021年第四季度(之前，HTTP跟踪中的敏感数据本应被编辑，但我们在HTTP/2请求中未能做到这一点。
参见Jeff King提交的b66c77a(2021年9月22日((peff(
(由Junio C Hamano合并——gitster——于2021年10月3日提交58e2bc4(
http：在编校时不区分大小写地匹配标头签字人：Jeff King
当HTTP/2正在使用时，我们无法正确地编辑"；授权"；
GIT_TRACE_CURL输出中的(和其他(标头。我们在
CURLOPT_DEBUGFUNCTION回调curl_trace()中获取头
它将它们传递给curl_dump_header()，后者依次检查redact_sensitive_header()
我们将标题视为文本缓冲区，如：Host: ... Authorization: Basic ...在将其分解成行之后，我们使用
skip_prefix()来匹配每个标头
这是区分大小写的，即使HTTP标头不区分大小写
这在过去是可靠的，因为这些标头是由curl本身生成的，它发送的内容是可预测的。但是当使用HTTP/2时；授权："；标头，但我们无法匹配它。
修复方法很简单：我们应该与skip_iprefix()匹配。还有另一种方法可以证明这个问题(以及我最初是如何发现它的(
查看GIT_TRACE_CURL相对于github.com的输出，您将看到未经编辑的输出，即使您没有设置http.version
这是因为设置curl只需要在其HTTP/1.1请求中发送额外的头；嘿，我说HTTP/2；升级，如果你也这样做">
但对于使用https的生产站点，服务器通过ALPN(TLS扩展(进行广告，称其支持HTTP/2，客户端可以立即开始使用它。
这看起来像是git、git凭据管理器和宣布支持NTLM的服务器之间的交互问题。
在github:上发现此问题
- OP表示，他通过在凭据管理器中手动设置目标域的登录名/密码来解决了这个问题
- 维护人员建议也尝试在git-config中设置
git config credential.authority basic