我正在使用几个存储库,但最近我只在我们的内部存储库中工作,一切都很好。

今天我不得不提交并将代码推到另一个,但我遇到了一些麻烦。

$ git push appharbor master
error: The requested URL returned error: 403 while accessing https://gavekortet@appharbor.com/mitivo.git/info/refs?service=git-receive-pack
fatal: HTTP request failed

没有什么我能做的,这将再次带来密码输入。

我如何重置系统上的凭据,以便Git询问我该存储库的密码?

我试过:

Git配置——global——unset core.askpass

以便取消设置密码

Git配置凭证。Helper '缓存超时=1'

为了避免凭证缓存…

似乎什么都不管用;谁有更好的主意?


当前回答

我遇到了与op相同的问题。它正在取我存储在系统某处的旧Git凭据,而我想将Git与我的新凭据一起使用,所以我运行了该命令

$ git config --system --list

它显示

credential.helper=manager

每当我执行git推送时,它都会使用我的旧用户名,我设置了很久,我想使用新的GitHub帐户来推送更改。我后来发现我的旧GitHub帐户凭据存储在 控制面板→用户帐户→凭证管理器→管理Windows凭证。

我只是删除了这些凭据,当我执行git推送时,它要求我提供我的GitHub凭据,它就像一个魅力。

其他回答

根据@patthoyts的高票数回答:

他的回答使用但没有解释本地、全局和系统配置。官方git文档在这里,值得一读。

例如,我在Linux上,不使用系统配置,所以我从不使用——system标志,但通常需要区分——local和——global配置。

我的用例是我有两个Github证书;一个用来工作,一个用来玩。

以下是我会如何处理这个问题:

$ cd work
# do and commit work
$ git push origin develop
# Possibly prompted for credentials if I haven't configured my remotes to automate that. 
# We're assuming that now I've stored my "work" credentials with git's credential helper.

$ cd ~/play 
# do and commit play
$ git push origin develop                                                                   
remote: Permission to whilei/specs.git denied to whilei.                
fatal: unable to access 'https://github.com/workname/specs.git/': The requested URL returned error: 403

# So here's where it goes down:
$ git config --list | grep cred
credential.helper=store # One of these is for _local_
credential.helper=store # And one is for _global_

$ git config --global --unset credential.helper
$ git config --list | grep cred
credential.helper=store # My _local_ config still specifies 'store'
$ git config --unset credential.helper
$ git push origin develop
Username for 'https://github.com': whilei
Password for 'https://whilei@github.com':
Counting objects: 3, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 1.10 KiB | 1.10 MiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To https://github.com/whilei/specs.git
   b2ca528..f64f065  master -> master

# Now let's turn credential-helping back on:
$ git config --global credential.helper "store"
$ git config credential.helper "store"
$ git config --list | grep cred
credential.helper=store # Put it back the way it was.
credential.helper=store

同样值得注意的是,有一些方法可以完全避免这个问题,例如,您可以使用~/。ssh/config与Github相关的ssh密钥(一个用于工作,一个用于娱乐),以及相应的自定义命名的远程主机,以解决身份验证的上下文化。

实际上useHttpPath是一个git配置,它应该适用于所有gcm。纠正。

原题摘要

在Windows上使用git 在GitHub上开发多个存储库 用于另一个GitHub存储库的错误凭据

虽然标题说“删除凭据”,但描述让我假设你可能在GitHub上有多个帐户,例如用于与工作相关的或私人项目。(至少那期杂志让我找到了这个话题。) 如果是这样,继续读下去,否则,忽略这个答案,但它在某些时候可能会派上用场。

原因

Git凭据管理器(简称GCM),就像微软的GCM一样,默认情况下为每个主机存储凭据。 这可以通过检查Windows凭据管理器来验证(参见关于如何在英语、法语和德语Windows版本上访问它的其他答案)。 因此,在同一主机上使用多个帐户(这里是github.com)在默认情况下是不可能的。

2020年10月,Windows版GCM已弃用,并被GCM Core所取代。这里的信息仍然适用于新的GCM,它甚至应该使用GCM为Windows存储的凭证。

解决方案

配置git以包含存储库的完整路径,作为每个凭据条目的附加信息。在Windows的GCM中也有文档。 我个人更喜欢包含HTTP(S)[存储库]路径,以便能够为每个存储库使用单独的帐户。

对于所有可能的主机:

git config --global credential.useHttpPath true

仅适用于github.com:

git config --global credential.github.com.useHttpPath true

看看GCM和git文档,也许你想指定一些不同的东西。

从Windows当前登录用户文件夹中的。gitconfig文件中删除这一行:

[credential]
helper = !\"C:/Program Files (x86)/GitExtensions/GitCredentialWinStore/git-credential-winstore.exe\"

这对我来说很有效,现在当我按下遥控器时,它又会要求我输入密码。

git config --list

将显示证书。Helper = manager(这是在Windows机器上)

要禁用当前本地git文件夹的缓存用户名/密码,只需输入

git config credential.helper ""

这样,git每次都会提示输入密码,忽略“管理器”中保存的内容。

在Windows 10专业版上使用最新版本的Windows git,我遇到了类似的问题,我有两个不同的GitHub帐户和一个Bitbucket帐户,所以VS2017、git扩展和git bash的情况有点混乱。

我首先检查了git是如何处理我的凭据与这个命令(运行git bash与提升命令或你得到错误):

git config --list

我找到了条目凭据管理器,所以我点击开始按钮>键入凭据管理器,然后左键单击凭据管理器黄色安全图标,启动了应用程序。然后我点击Windows凭据选项卡,找到了我当前git帐户的条目,碰巧是Bit-bucket,所以我删除了这个帐户。

但这并没有做到这一点,所以下一步是取消凭据,我从我的笔记本电脑上的存储库目录,其中包含我试图推到远程的GitHub项目。我输入了以下命令:

git config --system --unset credential.helper

然后我做了一个git推送,我被提示输入一个GitHub用户名(我需要的正确的一个),然后相关的密码,一切都被正确推送。

我不确定这是一个多大的问题,大多数人可能工作在一个存储库,但我必须跨几个工作,使用不同的提供商,所以可能会再次遇到这个问题。