git 由于身份验证问题卡在获取
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/36479201/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Stuck at fetch due to authentication issue
提问by Fabricio
I have a Jenkins (2.0 Beta-2) server running on Windows 2012 R2 x64, with a new build configured to get source files from TFS GIT (2013). I have already installed the Git for Windows version provided by Microsoft - the one that claims to solve the authentication issue between GIT CLI and TFS GIT.
我有一个在 Windows 2012 R2 x64 上运行的 Jenkins（2.0 Beta-2）服务器，新版本配置为从 TFS GIT（2013）获取源文件。我已经安装了微软提供的 Git for Windows 版本——声称可以解决 GIT CLI 和 TFS GIT 之间的身份验证问题。
My .gitconfig looks like this:
我的 .gitconfig 看起来像这样：
[credential]
helper = manager
interactive = never
validate = false
integrated = true
Jenkins is running under a service account, with no interactive session. This service account is member of the local admin group on the build server, and is properly configured as a contributor on TFS. The issue here is that when the Jenkins build starts, it hangs during the following command:
Jenkins 在服务帐户下运行，没有交互会话。此服务帐户是构建服务器上本地管理员组的成员，并已正确配置为 TFS 上的贡献者。这里的问题是当 Jenkins 构建开始时，它在以下命令期间挂起：
git.exe -c core.askpass=true fetch --tags --progress http://my.tfs.server:8080/tfs/collection/_git/MyProject +refs/heads/*:refs/remotes/origin/*
To me, it seems clear that it is stuck, asking for credentials, even though I have set it to use the git-credential-manager. I have also tried to store the service account credentials, using the "store" command from the GCM, but it fails with an weird error (the syntax to use it is quite confusing, so it is possible that I'm doing something wrong while trying it).
对我来说，即使我已将其设置为使用 git-credential-manager，它似乎也很明显卡住了，要求提供凭据。我还尝试使用 GCM 中的“store”命令存储服务帐户凭据，但它失败并出现奇怪的错误（使用它的语法非常混乱，因此我可能在做错事时试试看）。
回答by Nick Jones
For us, unsetting the "credential.helper" git config variable entirely was the answer. Our jobs were hanging at the exact same spot after upgrading from Git 2.5.0 to 2.8.4, and our Jenkins service is running as Local System, so doing the following unset the variable:
对我们来说，完全取消设置“credential.helper”git 配置变量就是答案。从 Git 2.5.0 升级到 2.8.4 后，我们的工作挂在完全相同的位置，并且我们的 Jenkins 服务作为本地系统运行，因此执行以下操作取消设置变量：
git config --global --unset credential.helper
git config --system --unset credential.helper
No reboot or uninstall/reinstall was necessary. After that, builds from Git succeeded.
无需重新启动或卸载/重新安装。之后，从 Git 构建成功。
The Jenkins Git Client plugin appears to rely on the GIT_ASKPASSvariable being set, which according to credential helper documentationis used when there are no credential helpers defined.
Jenkins Git 客户端插件似乎依赖于设置的GIT_ASKPASS变量，根据凭证帮助器文档，当没有定义凭证帮助器时使用该变量。
回答by Fabricio
After digging for a while I've found that I was not using the correct version of Git for Windows. It is known that the "standard" Git for Windows doesn't work very well with TFS GIT, mainly due to the lack of Kerberos support. I thought I was using the right version, but I wasn't.
挖掘了一段时间后，我发现我没有使用正确版本的 Git for Windows。众所周知，Windows 的“标准”Git 不能很好地与 TFS GIT 配合使用，主要是由于缺乏 Kerberos 支持。我以为我使用的是正确的版本，但我不是。
As part of the build environment setup, I installed Visual Studio 2015. Along with it, it installs an incompatible version of Git for Windows, the one that doesn't work with TFS GIT (I really don't know why!). Even after installing the Git Credential Manager for Windows, the installed GIT version remains as the incompatible one.
作为构建环境设置的一部分，我安装了 Visual Studio 2015。同时，它还安装了一个不兼容的 Git for Windows 版本，该版本不适用于 TFS GIT（我真的不知道为什么！）。即使在安装了适用于 Windows的Git Credential Manager之后，安装的 GIT 版本仍然是不兼容的版本。
Long story short: I had to manually uninstall both GIT and GCM, and install just GCM - which will then install the correct version of the GIT client during its installation.
长话短说：我必须手动卸载 GIT 和 GCM，然后只安装 GCM - 然后它会在安装过程中安装正确版本的 GIT 客户端。
After that, just reboot your server and things should "magically" work.
之后，只需重新启动您的服务器，事情就会“神奇地”工作。
