适用于：主要在 WSL 中开发、公司 GitLab 为自部署实例、仓库当前只能通过 HTTP Basic Authentication 使用的环境。
本文重点解决两个问题：凭据应该存在哪里，以及 不同 WSL 隔离策略下应该选哪种方案。
1. 适用场景与核心结论
典型场景如下：
- 开发环境主要在 WSL 中；
- GitLab 为公司自部署实例；
- Git 仓库只能通过
http://访问； - 认证方式只有用户名 + 密码，或者至少当前只能按 HTTP Basic Authentication 使用；
- 希望避免每次
git pull、git push、git fetch都重新输入密码； - 同时又不希望简单地把密码明文写进
~/.git-credentials； - Windows 主机上可能已经安装 Git for Windows 和 Git Credential Manager（GCM）；
- WSL 可能做了不同程度的隔离，例如不继承 Windows PATH、限制 Windows 环境变量，甚至完全关闭 Windows/WSL interop。
示例仓库地址：
http://gitlab.xxx/group/project.git这里最重要的结论是：
WSL 并不是只能在
credential.helper store和“每次手输密码”之间二选一。能否复用 Windows Credential Manager，关键不在于“WSL 能不能看到 Windows 环境变量”，而在于 WSL 是否还能启动 Windows 进程，以及 Windows 磁盘是否可访问。
如果彻底关闭 Windows interop，WSL 仍然可以使用 Linux 自己的安全凭据方案，例如 GCM + GPG/pass、Secret Service，或者退一步使用只存内存的 credential cache。
2. 先选方案：30 秒决策
2.1 决策树
WSL Git 需要保存公司 GitLab 凭据 │ ▼ WSL 能启动 Windows EXE 吗？ │ │ 能 不能 │ │ ▼ ▼ Windows 磁盘/GCM 可访问？ 完全按 Linux 处理 │ │ │ 是 否 ├─ 想长期安全保存 │ │ │ ↓ ▼ ▼ │ Linux GCM Windows GCM Linux 本地方案 │ + GPG/pass + WinCred │ │ ├─ 不想配密钥 │ │ ↓ │ │ credential cache │ │ │ └─ 必须永久保存且无其他办法 │ ↓ │ credential store │ （明文，最后手段） ▼ 公司 GitLab 只有 Basic？ │ 是 │ ▼ provider = generic │ ▼ HTTP 是否触发 GCM 拒绝？ │ │ 否 是 │ │ ▼ ▼ 保留安全警告 明确接受风险后再考虑 allowUnsafeRemotes=true2.2 方案对比
| 场景 | 推荐方案 | 磁盘上是否明文 | 重启后是否保留 | 推荐度 |
|---|---|---|---|---|
| WSL 可启动 Windows EXE | Windows GCM + Windows Credential Manager | 否 | 是 | ★★★★★ |
| WSL 完全隔离，允许安装 GPG/pass | Linux GCM + GPG/pass | 否，加密保存 | 是 | ★★★★★ |
| WSL 有完整桌面 Secret Service | Linux GCM + Secret Service | 否 | 是 | ★★★★☆ |
| WSL 完全隔离，不想配置密钥 | Git/GCM credential cache | 否，只在内存 | 否 | ★★★★☆ |
| 无安全存储、又必须长期保存 | credential.helper store | 是 | 是 | ★☆☆☆☆ |
对于这种公司 GitLab 场景，建议优先顺序是：
Windows GCM + Windows Credential Manager ↓Linux GCM + GPG/pass ↓Linux Secret Service ↓credential cache ↓credential store（最后手段）但还有一个更大的安全前提：
HTTPS / SSH 优于HTTP无论本地凭据保存得多安全，HTTP 都不能保护网络传输过程中的用户名和密码。
3. 判断 WSL 与 Windows 的隔离程度
很多配置问题都来自把“环境变量、PATH、Windows interop、Windows 磁盘挂载”混成一件事。先把这四件事分开。
3.1 Windows 环境变量是否传入 WSL
例如 Windows 中存在：
GIT_EXEC_PATHHTTP_PROXYHTTPS_PROXY某些公司自定义变量这些变量是否进入 WSL，是一类问题。
WSL 可以通过 WSLENV 等机制在 Windows 与 Linux 之间传递特定环境变量，但这和“能不能执行 Windows 程序”不是一回事。
因此：
WSL 看不到某个 Windows 环境变量并不等于：
WSL 无法调用 git-credential-manager.exe3.2 appendWindowsPath=false
/etc/wsl.conf 可以配置：
[interop]appendWindowsPath=false它的作用是：
不把 Windows PATH 中的目录自动追加到 WSL 的
$PATH。
结果可能是：
cmd.exepowershell.exegit-credential-manager.exe直接输入时找不到。
但是只要：
[interop]enabled=true仍然可以通过显式路径启动 Windows 程序，例如：
/mnt/c/Windows/System32/cmd.exe /c ver或者：
/mnt/d/Git/mingw64/bin/git-credential-manager.exe --version所以：
关闭 Windows PATH 注入，不等于关闭 Windows interop。
3.3 [interop] enabled=false
如果配置为：
[interop]enabled=falseappendWindowsPath=false这才是更彻底的隔离。
此时 WSL 不能正常启动 Windows 进程，因此类似下面的方案失效：
/mnt/d/Git/mingw64/bin/git-credential-manager.exe即使那个文件在 /mnt/d/... 下能够看见，也不能再依赖它作为 Windows 程序运行。
此时应当把 WSL 当成一台独立 Linux 主机，使用 Linux 本地凭据方案。
3.4 Windows 磁盘是否挂载
即使 interop 仍开启，如果公司安全策略又关闭了 Windows 磁盘自动挂载，例如没有：
/mnt/c/mnt/d/mnt/e那么 WSL 也无法直接通过：
/mnt/e/tool/git/...访问 Windows 上的 GCM。
这种情况下有两个方向：
- 如果策略允许，手动挂载相应 Windows 驱动器后继续复用 Windows GCM；
- 如果策略本来就是为了隔离 Windows 文件系统，则直接使用 Linux 本地凭据存储。
3.5 三步快速判断当前环境
可以先检查：
cat /etc/wsl.conf重点看：
[interop]enabled=...appendWindowsPath=...再测试：
/mnt/c/Windows/System32/cmd.exe /c echo WSL-interop-ok情况 A：命令能够运行
说明 Windows interop 仍然可用。
即使：
command -v cmd.exe没有输出，也可能只是：
appendWindowsPath=false此时仍然可以考虑复用 Windows GCM。
情况 B：显式路径也无法启动 Windows EXE
通常说明：
[interop] enabled=false；或- WSL/企业策略禁止 Windows 进程互操作；或
- Windows 驱动器根本没有挂载到 WSL。
此时应直接选择本文的 Linux 本地方案：长期保存优先使用 Linux GCM + GPG/pass；不想配置密钥时使用 credential cache。
4. 方案 A：WSL 复用 Windows Git Credential Manager（优先推荐）
4.1 适用条件
适用于：
- Windows 已安装 Git for Windows；
- Windows GCM 能正常工作；
- WSL 仍然允许 Windows interop；
- WSL 可以访问 GCM 所在 Windows 磁盘；
- 希望 Windows Git 和 WSL Git 共用同一套凭据。
这是最省事的方案。
结构如下：
WSL Git ↓Windows git-credential-manager.exe ↓Windows Credential Manager ↓公司 GitLab 用户名 / 密码密码不会以 Git 的 ~/.git-credentials 明文形式存放在 WSL 中。
4.2 确认 Windows GCM 正常
在 Windows PowerShell 中：
git credential-manager --version例如可能显示：
2.6.1+...再运行：
git credential-manager diagnose如果显示：
Diagnostic summary: ... passed, 0 failed说明 GCM 本身工作正常。
diagnose生成的日志可能包含敏感信息。不要直接把完整日志发送到聊天、工单或公共仓库。
4.3 找到 GCM，并在 WSL 中验证可执行
如果不知道 git-credential-manager.exe 的实际位置，可以直接在 Git for Windows 的安装目录中搜索。以下路径仅作为示例，实际安装目录以本机为准：
Get-ChildItem "D:\Git" ` -Filter "git-credential-manager.exe" ` -Recurse ` -ErrorAction SilentlyContinue | Select-Object -ExpandProperty FullName假设搜索结果为：
D:\Git\mingw64\bin\git-credential-manager.exe在 WSL 中通常对应：
/mnt/d/Git/mingw64/bin/git-credential-manager.exe直接测试：
"/mnt/d/Git/mingw64/bin/git-credential-manager.exe" --version如果能够返回版本号，说明 Windows 驱动器可访问、WSL interop 可用。即使 Windows PATH 没有注入 WSL，也不影响使用显式路径。
4.4 在 WSL Git 中设置 Windows GCM 为 helper
在 WSL 中执行：
git config --global credential.helper "/mnt/d/Git/mingw64/bin/git-credential-manager.exe"检查：
git config --show-origin --get-all credential.helper应该能够看到 WSL 自己的 ~/.gitconfig 中记录了该 helper。
如果路径包含空格，例如标准安装：
C:\Program Files\Git\mingw64\bin\git-credential-manager.exe可以按官方 WSL 示例写成：
git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"4.5 公司 GitLab 只有 HTTP Basic 时：使用 generic provider
如果公司 GitLab 明确只有：
HTTP+用户名+密码不需要 GitLab OAuth、浏览器登录、PAT 流程，那么最简单的是把该主机按 Generic HTTP Git 服务处理。
Windows PowerShell 中配置：
git config --global credential.gitlab.xxx.provider generic如果公司服务明确不使用 Windows 集成认证（NTLM/Kerberos），还可以：
git config --global credential.gitlab.xxx.allowWindowsAuth false这样 Generic provider 会直接走 Basic 用户名/密码逻辑，不必尝试 Windows Integrated Authentication。
为什么这里建议在 Windows PowerShell 中配置
当 WSL Git 调用的是：
Windows 版 git-credential-manager.exeGCM 自身运行在 Windows 环境中。
官方说明指出：这种模式下 GCM 默认读取的是 Windows Git 配置，而不是 WSL 的 ~/.gitconfig。
因此要区分：
WSL ~/.gitconfig └── 负责告诉 WSL Git：credential.helper 是哪个程序
Windows %USERPROFILE%\.gitconfig └── 负责配置 Windows GCM 自己的 provider、代理等行为这点很重要。
4.6 第一次认证后的流程
完成 WSL helper 和 Windows GCM provider 配置后，在 WSL：
git pull首次可能提示用户名和密码。
认证成功后结构变成：
WSL Git ↓Windows GCM ↓Windows Credential Manager ↓保存 gitlab.xxx 对应凭据之后：
git fetchgit pullgit push通常不需要重复输入。
Windows Git 和 WSL Git 还可以共享同一份 Windows 凭据。
5. 方案 B：完全隔离时使用 Linux GCM + GPG/pass
如果：
[interop]enabled=false或者公司明确要求：
WSL 不得调用任何 Windows 程序那么不要再绕回 Windows Credential Manager。
此时推荐：
WSL Git ↓Linux GCM ↓GPG/pass ↓加密后的凭据文件这是 WSL 内部相对完整的长期安全保存方案。
5.1 Linux GCM 并不是只能用明文 store
GCM 在 Linux 上支持多种 credential store，包括：
gpgsecretservicecacheplaintextnone
Linux 上默认不会替你自动选一个安全存储，需要自己配置。
其中对纯终端 WSL 最实用的是：
gpg5.2 安装 GPG 和 pass
以 Debian/Ubuntu 类发行版为例：
sudo apt updatesudo apt install gnupg pass生成 GPG key：
gpg --full-generate-key查看密钥：
gpg --list-secret-keys --keyid-format=long选择自己的 key ID 或 fingerprint，然后初始化 pass：
pass init <YOUR_GPG_KEY_ID>建议在 shell 环境中设置：
export GPG_TTY=$(tty)如果长期使用，可以放入：
~/.bashrc或对应 shell 的启动文件。
5.3 安装 Linux 版 GCM
当前 GCM 官方在 Linux 上支持安装为 .NET global tool。
按照当前官方安装方式，需要满足相应 .NET SDK 版本要求，然后：
dotnet tool install -g git-credential-managergit-credential-manager configure安装后检查：
git-credential-manager --version以及：
git config --show-origin --get-all credential.helper5.4 让 Linux GCM 使用 GPG/pass
git config --global credential.credentialStore gpg公司 GitLab 继续配置为 Generic：
git config --global credential.gitlab.xxx.provider genericLinux 下没有 Windows Integrated Authentication，因此不需要配置：
allowWindowsAuth之后：
git pull第一次输入 GitLab 用户名和密码，GCM 会通过 GPG/pass 保存加密凭据。
默认的 pass-compatible store 通常在：
~/.password-store里面是 GPG 加密后的数据，而不是 username:password 明文。
5.5 GPG/pass 的特点
优点：
- 密码不是明文保存在 WSL 文件系统；
- 不依赖 Windows Credential Manager；
- 适合完全关闭 interop 的 WSL；
- 可以长期保存；
- 纯终端环境也可以使用。
代价：
- 第一次配置比
store麻烦； - 需要维护 GPG 私钥；
- GPG 私钥有口令时，首次使用可能需要输入 GPG key passphrase；
- gpg-agent 的缓存状态会随着 WSL 会话生命周期变化。
如果只是保存 GitLab 登录密码，GPG 私钥丢失通常不会导致仓库数据丢失，但需要重新建立凭据存储并重新输入 GitLab 密码。
6. 其他可选方案
6.1 不长期保存：credential cache
如果你不想安装 GPG，也不希望密码落盘，Git 自带的 credential cache 非常实用。
例如缓存 8 小时：
git config --global credential.helper 'cache --timeout=28800'其中：
28800 秒 = 8 小时流程：
第一次 git pull ↓输入用户名密码 ↓credential-cache daemon 保存在内存 ↓8 小时内复用 ↓超时 / daemon 退出 / WSL 关闭 ↓凭据消失Git 官方说明 credential-cache 把凭据保存在内存中的 daemon 中，而不是长期写入磁盘。
优点：
- 配置非常简单；
- 不在磁盘保存 GitLab 密码；
- 适合每天启动一次 WSL 的开发习惯；
- 不依赖 Windows；
- 不要求 GPG。
缺点：
- 超时后必须重新输入；
- WSL 关闭后通常要重新认证；
- 不适合要求无人值守长期运行的 Git 操作。
如果你能接受“每天输入一次公司 GitLab 密码”，这个方案其实非常平衡。
如果已经安装 Linux GCM，也可以让 GCM 使用 cache
git config --global credential.credentialStore cache默认缓存时间通常为 900 秒。
可以设置：
git config --global credential.cacheOptions "--timeout 28800"这种方式是：
Git→ GCM→ Git credential cache而直接：
git config --global credential.helper 'cache --timeout=28800'则是：
Git→ Git credential-cache如果你的公司 GitLab 只需要最普通的 HTTP Basic 用户名/密码，实际上不一定需要为了 cache 专门安装 GCM。
6.2 Linux GCM + Secret Service
GCM 在 Linux 上还支持：
git config --global credential.credentialStore secretservice它使用 freedesktop Secret Service / libsecret 体系。
这种体验更接近桌面 Linux 的系统钥匙串。
但要注意：
GCM 官方说明该方式需要图形会话来解锁 secret collection。
因此在普通无桌面的 WSL、纯 SSH shell、服务器型 WSL 环境里，它往往没有 GPG/pass 稳定。
如果你的 WSL 具备完整桌面/WSLg 环境，也不能仅因为“有 GUI”就假设已经存在可用 Secret Service daemon；还需要实际安装并运行对应组件。
因此通常不把它作为 WSL 首选。
6.3 credential.helper store：只作为最后手段
最简单的是：
git config --global credential.helper store然后：
git pull输入用户名和密码后，Git 通常会写入：
~/.git-credentials内容本质上类似：
http://username:password@gitlab.xxx这是明文。
即使执行：
chmod 600 ~/.git-credentials也只是限制其他 Linux 用户直接读取该文件，并没有对密码做加密。
因此：
chmod 600不能把 store 变成安全密钥库。
不建议用 cat ~/.git-credentials 验证
下面这条命令会直接显示凭据文件内容：
cat ~/.git-credentials不推荐这样做，因为会直接把密码显示在：
- 终端；
- 截图；
- shell 录屏；
- 日志系统；
- 聊天粘贴内容。
需要确认文件是否存在，只看：
ls -l ~/.git-credentials即可。
不要把 .git-credentials 内容复制到聊天、工单、Wiki 或代码仓库。
7. 几个容易踩坑的关键细节
7.1 GCM 与 Windows Credential Manager 不是两个互斥方案
容易出现一个误解：
方案 A：GCM方案 B：Windows Credential Manager实际上在 Windows 默认情况下，关系是：
Git ↓Git Credential Manager ↓Windows Credential ManagerGCM 是 Git 与系统凭据存储之间的 credential helper；Windows Credential Manager 是底层安全存储之一。
Windows 上 GCM 默认使用：
wincredman因此通常不需要手工去“控制面板 → 凭据管理器”创建 GitLab 条目。
更合理的方式是：
让 Git/GCM 自动创建和维护凭据手工维护 Windows Credential Manager 条目容易因为 target/service 名称不匹配导致：
凭据明明存在，但 Git 仍然询问密码7.2 Windows GCM 与 Linux GCM 读取的配置不同
这是实际排查时非常重要的一点。
WSL 调 Windows GCM
WSL Git→ Windows GCM EXE此时：
WSL Git 配置
通常位于：
/home/<user>/.gitconfig主要负责：
credential.helper = Windows GCM 路径Windows GCM 配置
通常从 Windows Git 配置读取，例如：
%USERPROFILE%\.gitconfig因此：
providerautoDetectTimeoutallowWindowsAuth代理相关配置如果是给 Windows GCM 使用，通常应在 Windows Git 那边设置。
WSL 安装 Linux GCM
WSL Git→ Linux GCM此时 GCM 本身运行在 Linux 中，就使用 WSL/Linux 的 Git 配置。
例如：
git config --global credential.gitlab.xxx.provider genericgit config --global credential.credentialStore gpg都写入 Linux 用户的配置即可。
7.3 GitLab provider：generic 已经足够时，不必复杂化
GCM 的 GitLab provider 本身支持：
- Browser OAuth；
- Personal Access Token；
- Username/password。
理论上也可以配置为 GitLab provider，并限制为 Basic。
但是对于一个：
自建 GitLab只有 HTTP Basic没有 OAuth不需要 GitLab API 认证流程的服务器，generic 更直接，也更不容易触发 GitLab 专用 OAuth/探测逻辑。
因此这里默认：
provider = generic7.4 HTTP 与 credential.allowUnsafeRemotes
排查 HTTP 认证失败时，可能会用到这个配置：
git config --global credential.allowUnsafeRemotes true是否需要开启，要看 GCM 版本和 provider 的实际行为，不能只根据使用 HTTP 就决定。
它是什么
GCM 默认把未加密 HTTP 远程视为不安全 URL。
配置：
git config --global credential.allowUnsafeRemotes true表示明确允许 GCM 在不安全远程上发送凭据。
这是一个安全降级开关。
对 Generic provider，不一定必须开启
当前 GCM 的 Generic provider 对普通 HTTP 的行为是：
警告 HTTP 不安全而不是一律直接禁止 Basic 凭据。
因此对于：
provider = generic不应机械地认为 allowUnsafeRemotes=true 一定是必需项。
建议流程：
- 先设置
provider=generic； - 正常执行
git pull； - 如果只是收到 HTTP 风险警告，但认证正常，可以保留警告；
- 如果当前 GCM 版本/provider 明确拒绝不安全远程，而公司又只能 HTTP，再决定是否开启。
如果必须开启，应知道它是全局安全降级
例如 Windows GCM 使用 Windows Git 配置时：
git config --global credential.allowUnsafeRemotes true这不是“让 GitLab.xxx 变安全”，而是告诉 GCM：
我接受在不加密 HTTP 上发送凭据的风险因此只应在公司环境确实无法改 HTTPS/SSH 时使用。
7.5 同一 GitLab 多仓库、多账号
Git 默认主要按：
protocol + host匹配 HTTP 凭据。
也就是说同一个：
http://gitlab.xxx下面多个仓库，通常会共用一套用户名/密码。
对于公司统一账号，这正好是需要的行为。
如果某些特殊环境要求同一主机不同 path 使用不同凭据，可以进一步研究：
credential.useHttpPath但普通 GitLab 单账号场景不要随便开启，否则可能导致每个 group/project 都产生独立凭据，反而增加维护复杂度。
8. 常见排障与恢复
8.1 where.exe git-credential-manager.exe 找不到，不代表 GCM 不存在
Windows 中可能出现：
where.exe git能够找到：
D:\Git\cmd\git.exeD:\Git\bin\git.exe但：
where.exe git-credential-manager.exe却返回：
INFO: Could not find files for the given pattern(s).同时：
git credential-manager --version又能正常执行。
这是正常的。
原因是：
where.exe只按照 Windows PATH 搜索，而：
git credential-manager属于 Git 子命令机制，Git 还会从自己的执行目录中寻找：
git-credential-manager.exe因此真正要找 GCM 文件路径，建议直接搜索 Git 安装目录。
例如：
Get-ChildItem "D:\Git" ` -Filter "git-credential-manager.exe" ` -Recurse ` -ErrorAction SilentlyContinue | Select-Object -ExpandProperty FullName典型位置可能类似：
D:\Git\mingw64\bin\git-credential-manager.exe实际位置以搜索结果为准。
8.2 安全地清除错误凭据
优先使用 Git credential 接口
可以让 Git 通知当前 helper 删除对应凭据：
printf 'protocol=http\nhost=gitlab.xxx\n\n' | git credential reject这样不会把密码显示出来。
之后重新：
git pullGit/GCM 会再次要求输入。
credential cache 清空
如果使用的是 Git 内存 cache：
git credential-cache exit之后缓存 daemon 会退出，内存中的凭据被清除。
Windows Credential Manager
如果使用 Windows GCM，也可以通过 Windows：
控制面板→ 凭据管理器→ Windows 凭据检查/删除对应 Git 凭据。
也可以让 GCM/Git 自己 erase/reject，通常比手工创建条目更推荐。
8.3 helper 配错后的回退
先看当前 helper：
git config --show-origin --get-all credential.helper如果确认要移除全局 helper：
git config --global --unset-all credential.helper如果不存在该项，Git 可能返回非零状态，这是正常的。
查看所有 credential 相关配置：
git config --show-origin --get-regexp '^credential\.'不要在不知道来源的情况下直接删除系统级配置；先通过：
--show-origin确认是哪一个配置文件写入的。
8.4 WSL 侧排查命令
查看 Git：
git --versioncommand -v git查看 remote：
git remote -v查看 helper：
git config --show-origin --get-all credential.helper查看全部 credential 配置：
git config --show-origin --get-regexp '^credential\.'查看 WSL interop：
cat /etc/wsl.conf测试 Windows interop：
/mnt/c/Windows/System32/cmd.exe /c echo WSL-interop-ok测试指定 Windows GCM：
"/mnt/d/Git/mingw64/bin/git-credential-manager.exe" --version实际路径以本机搜索结果为准。
8.5 Windows 侧排查命令
确认 Git：
git --versionwhere.exe git确认 GCM：
git credential-manager --versiongit credential-manager diagnose查看 helper：
git config --show-origin --get-all credential.helper查看 credential 配置：
git config --show-origin --get-regexp '^credential\.'寻找 GCM EXE：
Get-ChildItem "D:\Git" ` -Filter "git-credential-manager.exe" ` -Recurse ` -ErrorAction SilentlyContinue | Select-Object -ExpandProperty FullName如果 Git 安装位置不同，替换根目录。
9. 安全边界：HTTP 才是最大的风险
本地凭据管理只能解决：
密码在本机怎么保存不能解决：
密码经过网络时怎么保护HTTP 没有 TLS。
Basic Authentication 也不是加密协议；凭据编码不能代替 TLS。
因此，即使使用：
Windows Credential Manager或者：
GPG/pass也只能保证密码在本地磁盘上不以普通明文形式保存。
当执行：
git pullgit push时，HTTP 链路本身仍然缺乏 HTTPS 提供的机密性与服务器身份验证。
所以真正理想的优先级仍然是：
HTTPS ↓SSH ↓HTTP + 安全本地凭据存储 ↓HTTP + 内存 cache ↓HTTP + 明文 store如果公司只能 HTTP，至少应尽量确保：
- 只在可信内网使用；
- 或必须先连接公司 VPN；
- 不在公共 Wi-Fi/不可信网络直接访问；
- 不把 GitLab 密码复用到其他重要系统；
- 推动 GitLab 最终提供 HTTPS 或 SSH。
9.1 无人值守脚本的额外注意事项
如果只有：
HTTP + 账号密码这本身就不是理想的无人值守认证设计。
不要简单把个人登录密码硬编码到：
- shell script；
.env；- Git remote URL；
- CI 配置明文；
~/.git-credentials。
更合理的是推动公司侧提供：
- HTTPS；
- SSH deploy key；
- deploy token；
- PAT；
- CI 专用凭据；
- 其他最小权限机器凭据。
如果公司当前确实不支持，只能根据企业安全要求选择受控的 secret store。
10. 官方资料
- Microsoft WSL advanced configuration /
wsl.conf - Git Credential Manager - WSL
- Git Credential Manager - Credential stores
- Git Credential Manager - Configuration
- Git Credential Manager - GitLab support
- Git - credential-cache
- Git - credential-store