如何在 Windows 的 Git Credential Manager 中的每个 repo 本地存储凭据？

Question

我有 2 个 github 帐户（工作和个人），我想在我的 Windows 10 中存储凭据（以安全方式） 。

git config --global credential.helper manager命令仅设置单个用户名和密码，这在我的机器中的个人仓库和工作仓库之间存在冲突。 两个 repo 都是使用 HTTPS 克隆的。

我想存储和访问可能基于 repo 用户名的不同凭据。 可能吗？

我知道 SSH 是一种选择，但我想知道 HTTPS 的方式。

Answer 1

URL 中的用户名

在 Bitbucket 上，您可以将用户名添加到远程的 HTTPS URL：

• 使用： https://JerryGoyal@bitbucket.org/path/repo.git
• 而不是： https://bitbucket.org/path/repo.git ://bitbucket.org/path/repo.git

由于 URL 在技术上有所不同，因此您可以根据需要将您的工作和个人分支添加为同一存储库的远程。 旧版 Git 凭据管理器的问题 #749表明 username-in-URL 技术也适用于 GitHub，但其他存储库主机可能不支持它。

设置useHttpPath

更一般地，您可以使用credential.useHttpPath为同一主机运行的多个存储库拆分凭据管理。 下面来自旧版 Git Credential Manager 文档的引用包括在bitbucket.com上设置它的命令行建议，但您可以根据自己的目的进行修改或查看较新的 GCM Core 文档中更长的示例文本。

useHttpPath

指示 Git 将远程 URL 的路径部分提供给凭证助手。 提供路径时，GCM 将在读取和/或写入凭据时使用主机名 + 路径作为密钥。

注意：此选项会更改 Git 的行为。

支持true或false 。 默认为false 。

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

正如rjmunro在评论中指出的那样，您可以删除--global以仅使用当前 repo 的路径。 如果是这样，您也可以删除主机名：

git config credential.useHttpPath true

如果您想随心所欲地使用不同的凭据登录到完全相同的存储库，则第二种方法无济于事。 （参见旧版 GCM #363 。）

Answer 2

您可以使用不同的助手来完成此操作，例如git-credential-store ，它采用可选参数作为凭据文件路径。 您可以在每个存储库的本地配置中进行设置，为每个存储库使用不同的凭据文件。

或者使用@phd评论中链接中的建议，该建议适用于Windows的Git Credential Manager

Answer 3

更一般地，您可以使用credential.useHttpPath为同一主机运行的多个存储库拆分凭据管理。 ^{[ ‡ ]}

在这种情况下，请使用 Git 2.27（2020 年第二季度），因为凭证助手的 URL 解析已更正。

请参阅Jeff King ( peff )的提交 4c5971e （2020 年 4 月 14 日）。
^{（由Junio C Hamano -- gitster --在提交 a397e9c中合并，2020 年 4 月 22 日）}

credential ：将 URL 中的“ ? ”和“ # ”视为主机的结尾

^{签字人：杰夫·金}

不寻常的看到：

 https://example.com?query-parameters

没有中间的斜线，例如：

 https://example.com/some-path?query-parameters

甚至：

 https://example.com/?query-parameters

但根据 RFC 3986，它是主机名（实际上是“权限组件”）的有效结尾。对于“ # ”也是如此。

curl将根据标准解析 URL，这意味着它将联系example.com ，但我们的凭据代码会询问一个带有“ ? ”的虚假主机名。

让我们确保我们遵循标准，更重要的是询问curl将与之交谈的相同主机。

如果我们可以让 curl 为我们解析 URL，那就太好了。
但它直到 7.62 才发展出 URL 解析 API，所以无论哪种方式，我们都会被后备代码困住。
另外，我们需要在主 Git 二进制文件中使用此代码，我们试图在其中避免对libcurl的链接依赖。

但至少让我们修复我们的解析器。 移动到curl的解析器可以防止其他潜在的差异，但这可以让我们立即解决已知问题，并且如果我们最终使用curl将有助于我们的后备代码。

---

使用 Git 2.35（2022 年第一季度），凭据和其他变量值受益于最新的 RFC 3986：在匹配每个 URL 配置变量名称时，将"_"视为 URL 中的任何其他 URL 有效字符。

请参阅Jeff King ( peff )的提交 e4c497a （2021 年 10 月 12 日）。
^{（由Junio C Hamano -- gitster --在提交 96eca02中合并，2021 年 11 月 29 日）}

urlmatch : 为URL_HOST_CHARS添加下划线

^{报告人：亚历克斯·韦特}
签字人：杰夫·金

在解析 URL 以对其进行规范化时，我们允许主机名仅包含点 (".") 或破折号 ("-")，以及用于 IPv6 文字的括号和冒号。
这与 RFC 1738 中的旧 URL 标准相匹配，该标准说：

 host = hostname | hostnumber hostname = *[ domainlabel "." ] toplabel domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit

但这后来被更自由的 RFC 3986 更新：

 host = IP-literal / IPv4address / reg-name reg-name = *( unreserved / pct-encoded / sub-delims ) unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

虽然其中带有下划线的名称并不常见，并且可能违反了某些 DNS 规则，但它们在实践中确实有效，我们很乐意通过 http://、git:// 或 ssh:// 与他们联系。
出于 URL 匹配的目的而忽略它们似乎很奇怪，尤其是当 URL RFC 似乎允许它们时。

这里不应该有任何不利之处。
它不是 URL 中语法上重要的字符，因此我们不会对解析感到困惑； 我们之前只是简单地拒绝了这样的 URL（这里的测试直接检查 url 代码，但明显的用户可见效果将无法匹配credential.http://foo_bar.example.com.helper或类似的配置http.<url>.* ）。

可以说我们也想在这里允许波浪号（“ ~ ”）。
同样可能没有缺点，但我没有添加它只是因为它似乎更不可能出现在主机名中。

Answer 4

每个主机（或 URI）不能有多个用户名。 据我所知，就目前而言，SSH 是最直接的，可以做你想做的事。

有关更多信息，您可以查看 VonC 对与您的问题非常相似的问题的回答。 GitHub：Windows 上两个帐户的单独凭据