Git HTTPS 串用了另一账号的凭据，按仓库路径区分认证

同一台电脑用两个账号访问同一代码托管域名。仓库 A 能正常拉取，仓库 B 却提示无权限，认证管理器显示的还是 A 的账号。若 remote 使用 HTTPS，先检查 Git 交给 credential helper 的查找范围：默认情况下，仓库路径不参与 HTTP 凭据匹配，同一主机下的仓库可能共用已有身份。

这是 HTTPS 凭据上下文的问题。user.name 和 user.email 只影响提交作者，不负责切换远端登录账号；浏览器切了账号，也不保证 Git 的 credential helper 同步切换。

在出问题的仓库检查 helper

在该仓库内查看实际配置及出处：

git config --show-origin --get-all credential.helper
git config --show-origin --get credential.useHttpPath

没有第二项输出时，不能理解为按路径隔离已经开启；HTTP(S) 默认不使用路径。第一项也可能有多条 helper，后续如何查找和存储要结合整个配置链，而不是只看某个全局值。

helper 可以是带参数的程序，甚至是 shell 片段，输出中可能带敏感信息。只在受控终端检查，分享前脱敏。不要为了确认登录账号执行并公开 git credential fill 的完整输出，它可能直接包含密码或 token。

同时核对 remote 真的使用 HTTPS，以及读写地址是否相同。已有 URL 内嵌密钥时先按安全流程处理；不要用“把密码加进 URL”来解决串号。对于 SSH remote，应检查密钥与 host 别名，而不是改这里的 HTTP 设置。

只给需要独立身份的仓库打开路径匹配

确认这个仓库需要按 HTTPS 路径区分账号后，先记录它原来的本地设置，再执行：

git config --local credential.useHttpPath true

它把设置限制在当前仓库。Git 随后会把仓库路径交给 helper，例如把 https://code.example.com/team-b/project.git 与另一团队的路径区分。实际如何储存和选择账号仍由 helper 决定，这个开关本身不储存密码，也不授予仓库权限。

路径上下文变化后，原来的主机级记录未必匹配，新请求可能要求重新认证。通过当前安全 helper 的正常流程选择正确账号，并确认该账号确有目标仓库权限。不要为消除提示改用明文 credential-store；反复提示还应检查 helper 是否能正常访问它的安全存储。

以 Git Credential Manager 为例，Windows 默认使用 Windows Credential Manager，macOS 默认使用 Keychain；Linux 的安全存储需要实际配置，不能假定安装程序后就已经能持久保存。不同提供商还可能有自己的上下文规则，Azure Repos 的 dev.azure.com 组织路径处理就不能照搬为任意完整路径存储。

同一个 URL 的两个账号，还需要账号选择

路径不同可以提供不同查找上下文；如果两个账号访问的是完全相同的仓库 URL，只开启 useHttpPath 并不能区分它们。此时还要使用 helper 支持的用户名上下文或账号选择方式。

不要把账号名写成密码，也不要靠随意追加端口制造假的地址。确认 helper 对该托管服务的支持后，为对应仓库选择正确身份。GitHub 的 HTTPS Git 认证也不能靠普通账号密码恢复，应使用组织允许的 OAuth、token 等方式。

原有主机级凭据可能还供别的仓库使用。不要一次删除 Windows 凭据管理器或 Keychain 中所有 Git 记录。确需清理错误记录时，先确认准确的主机、用户名及路径范围，防止让其他仓库一起失去登录状态。

用实际仓库验证权限

重新认证后，先做只读查询：

git ls-remote origin

确认请求使用了预期身份并能读取目标仓库，再执行原本需要的 fetch 或 push。读取成功不等于有写入权限；如果身份正确仍无法 push，应继续查账号、仓库、token 范围与组织授权，而不是反复切换缓存。

若要回退路径设置，恢复记录下来的本地原值。原来没有这个本地键时，只删除本次新加的键；不要顺手清空全局 helper。回退后可能重新匹配原来的主机级身份，因此还需要从原终端或 IDE 再验证一次。