在 WSL 中配置 Git 与凭据管理-未完纪

Git 用来记录文件的修改历史，便于比较变化、恢复早期版本，也便于多人把各自的工作合并到同一份代码中。在 WSL 中使用 Git，首先要分清 Windows 与 Linux 两套环境，再决定提交身份和远程仓库认证由哪一套配置负责。

Windows 与 WSL 各有自己的 Git 环境

安装 WSL 和 Linux 发行版之后，会得到与 Windows NTFS 文件系统分开的 Linux 文件系统。Linux 使用挂载点，而不是 C: 这样的盘符；根目录 / 是根文件系统的挂载点，目录树下面也可能挂载其他文件系统。

可以在发行版终端运行 cd ~ 回到主目录，再用 explorer.exe . 打开当前目录对应的 Windows 文件资源管理器窗口。官方文档用以下路径说明两套环境如何对应；Ubuntu 版本名称是原文的历史示例，不是当前推荐安装版本。

环境	从 Windows 访问用户主目录的路径示例
Ubuntu 20.04	`\\wsl$\Ubuntu-20.04\home\username`
Ubuntu 18.04	`\\wsl$\Ubuntu-18.04\home\username`
Debian	`\\wsl$\Debian\home\username`
Windows PowerShell	`C:\Users\username`

其中，username 和发行版名称都要替换为实际值。从 WSL 终端访问 Windows 上的 C:\Users\username 时，常见对应路径是 /mnt/c/Users/username。

在要使用 Git 的环境里分别安装和检查 Git：Windows 使用 Git for Windows，WSL 发行版使用该发行版的 Linux Git。二者的可执行文件、版本和配置文件可能不同。原文的版本截图所要说明的也是这一点；本文用路径表和文字保留这项信息，没有把旧版本截图当成当前安装结果。Microsoft Learn 原文

安装 Git

一些 WSL 发行版已经包含 Git。各发行版的包管理器不同，应先确认正在使用哪一个发行版，再参考 Git 的 Linux 下载说明。

Ubuntu/Debian 中，官方教程给出的安装命令是：

sudo apt-get install git

这会安装已配置软件源提供的版本。软件源中的稳定包不一定等于 Git 上游最新发布版本；不能只凭这个命令就声称已经装上“最新 Git”。Windows 端如需使用 Git，应另外安装 Git for Windows。本文没有执行安装或改变机器配置。

设置提交者姓名与邮箱

在你要使用的 WSL 发行版终端中设置提交者姓名：

git config --global user.name "Your Name"

把 Your Name 替换为希望显示在提交记录里的姓名，再设置提交者邮箱：

git config --global user.email "youremail@domain.com"

这里的姓名与邮箱用于提交记录，不是登录密码，也不会自动让 Git 获得远程仓库访问权。--global 作用于当前环境、当前用户的 Git 配置；Windows 与各个 WSL 发行版的配置需要分别理解。

需要直接编辑配置文件时，可以使用 nano ~/.gitconfig 等编辑器。如果还没有 GitHub 账号，可从 GitHub 注册，使用 GitHub 的 Git 入门资料学习基本操作。远程托管账号建议启用双重身份验证。

配置 Git Credential Manager

Git Credential Manager（GCM）是基于 .NET 的 Git 凭据帮助程序，可用于 WSL 1 和 WSL 2，并参与 GitHub、Azure DevOps、Azure DevOps Server、Bitbucket 等服务的认证流程。

使用 Windows 版本的 GCM 时，WSL 中的 Git 可以通过互操作能力调用它。GCM 完成托管服务认证后取得令牌，并通过 Windows 的凭据存储机制保管；后续访问可以复用已保存且仍有效的凭据。令牌过期、权限改变或服务要求再次认证时，仍可能出现登录提示，不能把“首次登录后可复用”理解为永远无需登录。

官方教程给出的最低 Windows 条件是 Windows 10 版本 1903，因为 GCM 与 WSL 互操作依赖相应的 wsl.exe 能力。GCM 项目推荐安装最新的 Git for Windows，其中包含 GCM，并在安装时选择该凭据帮助程序。这样可以让 Windows 和 WSL 共用 Windows 侧的凭据存储。GCM 的 WSL 配置文档

检查版本与设置帮助程序路径

Microsoft Learn 页面提供以下检查命令：

git --version; git credential-manager --version

第一项检查当前终端调用的 Git。第二项需要当前环境能把 GCM 识别为 Git 子命令；只安装了 Windows 端的 Git，并不保证 WSL 的命令搜索路径能直接找到它。如果第二项提示不是 Git 命令，应继续检查实际安装路径和凭据帮助程序配置，不能据此就断定 Windows 上没有 GCM。

当前 GCM 项目文档要求在 WSL 内把 Windows GCM 的可执行文件设为帮助程序。先确认文件实际存在，再选择与你安装版本和架构相符的一项命令，不要依次运行三项。

Git for Windows x64 的 v2.56.0 及以后版本，项目文档采用 ucrt64 路径：

git config --global credential.helper "/mnt/c/Program\ Files/Git/ucrt64/bin/git-credential-manager.exe"

Git for Windows x64 的 v2.55.x 及更早版本，项目文档采用 mingw64 路径：

git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/bin/git-credential-manager.exe"

Git for Windows ARM64 的已知版本，项目文档采用 clangarm64 路径：

git config --global credential.helper "/mnt/c/Program\ Files/Git/clangarm64/bin/git-credential-manager.exe"

上面保留了官方命令中处理 Program Files 空格的转义。自定义安装位置、安装到其他盘符或不同版本的布局，都可能需要修改路径。版本与架构路径依据

例如，确认采用 ucrt64 路径后，可以直接检查那个 Windows 可执行文件的版本：

"/mnt/c/Program Files/Git/ucrt64/bin/git-credential-manager.exe" --version

这条命令是本文补充的路径检查示例，其他安装布局应使用实际路径。本文只做了命令文本与路径规则核对，没有在 WSL 中运行检查，也没有读取任何凭据。

理解两套配置文件

默认情况下，作为 Windows 应用运行的 GCM 会通过 Git for Windows 查询配置。因此，WSL Git 中的代理等配置不一定自动被 GCM 使用。Windows 用户的配置通常位于 %USERPROFILE%\.gitconfig，WSL 中则位于对应发行版的 ~/.gitconfig，也可通过 \\wsl$\distro\home\$USER\.gitconfig 这样的 Windows 路径访问。

如果两个环境都需要代理等设置，应同时检查两侧配置。GCM 项目也提供让它回调 WSL Git 的配置方式，但这样得到的设置会与该 WSL 发行版关联，而非自然共享给所有发行版和 Windows 主机。共享配置说明

不安装 Git for Windows 时，有不同选择：可以按 GCM 项目文档配置独立的 Windows GCM，也可以将 Linux 版本直接安装到 WSL。后者以 Linux 应用运行，无法利用 Windows 主机的认证界面和凭据存储能力。完整步骤应以项目的无 Git for Windows 配置说明与安装说明为准，不能把这些方式与共享 Windows 凭据库混为一谈。

Microsoft Learn 还提示 GitHub CLI 的 keyring 问题。其链接指向 cli/cli #8954，描述的是特定环境下 gh auth login 的凭据存储行为；该工具与 GCM 的认证流程不能混为一项。本文保留问题入口，没有把报告中的具体版本与环境推广为所有 WSL 的必然行为。

HTTPS 与 SSH 的区别

GCM 处理的是 HTTP(S) 远程仓库认证。使用 SSH 远程地址时，应配置 SSH 密钥和相应服务的 SSH 认证，不会由 GCM 代替这套流程。

Azure DevOps 的附加设置

要使用 Azure Repos 或 Azure DevOps，官方教程要求在 WSL 中设置：

git config --global credential.https://dev.azure.com.useHttpPath true

该配置让面向这个 HTTPS 主机的凭据查询保留 URL 路径信息。配置好 GCM 后，相关 HTTPS Git 操作才能通过它取得凭据；已经缓存的适用凭据可以被复用，否则会触发认证提示。是否能够访问仓库仍取决于账号权限和服务要求。

如果使用 GPG 给提交签名，可参考关联 GPG 密钥与 GitHub 邮箱。提交签名与拉取、推送时的登录认证承担不同作用。

添加 .gitignore

为项目添加.gitignore，可以让 Git 忽略无需纳入版本控制的文件。GitHub 维护了按语言和工具组织的模板集合，例如 Node.js 模板。

从 GitHub 网站创建新仓库时，可以选择初始化 README、适合项目类型的 .gitignore，以及需要的许可证。模板是起点，仍要根据项目实际构建产物和文件用途调整。

配合 VS Code 使用

Visual Studio Code 自带 Git 支持。源代码管理视图可以显示改动，并提供暂存、提交等 Git 操作的入口。打开 WSL 中的项目时，仍要注意编辑器当前使用的环境与 Git 实例，避免把 Windows 侧设置误认成 WSL 侧设置。具体功能见 VS Code 的源代码管理说明。

保持行尾一致

同一个仓库如果会在 Windows、WSL 或容器中工作，应统一行尾规则。Windows 与 Linux 常用的行尾不同，自动转换设置又可能不同；结果是 Git 显示许多文件被修改，而内容变化实际上只有行尾。

官方教程给出两类处理方式：使用仓库中的 .gitattributes 明确行尾规则，或在 Windows 侧调整全局转换配置。应根据项目约定选择，并检查现有文件状态；本文没有执行全局配置修改或批量规范化文件。进一步排查可参考 VS Code 的远程开发疑难解答。

延伸资料

WSL 与 VS Code
GitHub Learning Lab：官方原文列出的学习入口，本文保留来源，不宣称该旧课程体系仍适合当前学习路径。
Git 可视化工具
Pro Git：凭据存储

来源、修订与许可

正文依据 Microsoft 官方文档团队的《在适用于 Linux 的 Windows 子系统上使用 Git 入门》完整整理和中文校订；访问时页面显示更新日期为 2025-10-04。对应文档源码的 ms.date 为 2025-08-22，二者不是同一元数据字段。本文核对日期为 2026-10-03。

修改包括：校正中文排版与措辞；把发行版路径和旧版本截图的关键内容改为表格说明；解释发行版软件源与上游最新版本的区别；依据 GCM 当前官方文档补充帮助程序路径、版本和架构条件；明确提交身份、GCM、SSH 与 GPG 签名的用途边界。未声称安装、登录或命令执行成功。

MicrosoftDocs/WSL 的正文采用 CC BY 4.0，其仓库许可证包含许可条件及不提供担保的说明。本文的整理与补充不表示得到 Microsoft 或 GCM 项目的认可。

文中的 Microsoft 文档代码示例适用仓库代码 MIT 许可；GCM 文档中的路径命令适用其项目 MIT 许可。相关版权与共同许可条款保留如下：

The MIT License (MIT)

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

文章版权归作者所有，未经允许请勿转载。

THE END