Windows 安装 Git 完整指南：从环境变量到 SSH 免密配置

2026 年了，Git 在 Windows 上的安装教程依然是搜索热门，这一点我一点都不意外。很多新手从 GitHub 上把项目压缩包下载下来，解压完发现没法随时拉取更新；还有人用 VS Code 提交代码时被反复要求输入密码；更有人在命令行敲 git 却收到“不是内部或外部命令”。这几点本质上都指向同一件事：Git 本体没装对、环境没配好、SSH 密钥没打通。这篇文章我按自己重装过十几台 Windows 开发机的经验，把下载、安装、环境变量、身份与换行符配置、SSH 密钥生成与验证的完整流程一次讲透，适合刚接触版本控制的人，也适合一直用 HTTPS 密码登录、想彻底切到 SSH 免密的老手。

1. 别急着下一步：Windows 安装 Git 前需要想清楚的几件事

1.1 官网下载哪个文件：64 位安装包是最省心的选择

先说版本选择。你现在去 Git 官网的 Downloads 页面，Windows 版本会提供 64-bit 和 32-bit 两种安装包。2026 年了，绝大多数 Windows 10/11 机器都是 64 位系统，直接下载 64-bit 的.exe安装包就行。

想知道自己系统是几位，可以按Win + R，输入winver查看系统信息；或者在“设置 -> 系统 -> 系统信息”里看系统类型。如果你还在用 32 位系统，我不太建议继续在这台机器上做开发了，因为现在的 Node.js、Python、Docker 工具链对 32 位支持越来越少。

这里有个容易踩的坑：官网页面里还有一个 “Portable"便携版，也就是免安装版。日常写代码、做项目，我建议选标准安装包，不要选 Portable。便携版虽然有免安装的优点，但默认不会集成到右键菜单，也不会主动配置好 PATH 环境变量，后期用起来会多很多麻烦。你是新手的话，标准安装包一路往下走是最稳的。

如果官网下载速度不太理想，可以考虑国内开源软件镜像站，比如清华 TUNA、阿里云镜像，搜索 “Git for Windows” 就能找到对应版本。下载后先校验一下文件签名，不过对个人开发者来说，直接从官网或可信镜像站下载基本不会有问题。

1.2 安装向导里的关键选项：不要一路默认到底

Git for Windows 的安装向导确实可以一路 “Next” 装完，但有几个选项会影响后续使用体验，我建议你在安装的时候稍微停一下。

第一个是选择组件。默认会把 Git Bash、Git GUI、Git LFS 等组件都选上，这没问题，重点是把 “Git Bash Here” 和 “Git GUI Here” 这两个右键菜单选项勾上。装完之后，你在任意文件夹里右键，就能直接打开 Git Bash，非常实用。桌面快捷方式这些可勾可不勾，我一般去掉，桌面干净一点。

第二个是默认编辑器。Git 在某些场景下会调用一个文本编辑器让你写提交信息，比如执行git commit不带-m参数的时候。默认是 Vim，很多 Windows 用户进去之后不知道怎么退出，卡在编辑器里进退两难。我建议在安装向导里把默认编辑器改成 VS Code 或者 Notepad++。如果你已经装了 VS Code，这一步会很舒服。

第三个是 PATH 环境变量选项。这里有三个单选项，大概意思是：

• 仅使用 Git Bash
• 从命令行和第三方软件中使用 Git（推荐）
• 不修改 PATH

请选择中间那项 “Git from the command line and also from 3rd-party software”。选这一项，安装程序会把 Git 的cmd目录写进 PATH，这样你才能在 CMD、PowerShell、VS Code 终端里直接使用git命令。如果你选了第一项或第三项，后面经常会出现“命令找不到”的情况，尤其是 VS Code 里会报 Git 未安装。

第四个是换行符转换方式。默认选项 “Checkout Windows-style, commit Unix-style line endings” 对应core.autocrlf=true，这是大多数 Windows 用户的选择。这个字段会在后面第 3 章详细讲，这里先保留默认，但你要知道它不是玄学。

还有一个不算关键但容易误导人的选项：安装到最后有一个 “Enable symbolic links” 勾选项。不建议勾。Windows 上的符号链接需要管理员权限，而且很多普通用户根本用不到，勾了反而会在创建软链时报错。保持默认不勾就行。安装完成后，先别急着用，把环境变量这关过了。

2. 装完不认账？环境变量与命令行接入自检

2.1 三条命令确认安装是否真的成功

很多人装完 Git 后，打开终端敲git --version，结果提示找不到命令，第一反应是重装。其实问题往往只是终端没有刷新环境变量。你先重新开一个终端窗口，再试一次。

打开 Git Bash，或者在 CMD / PowerShell 里执行：

git --version

正常情况下会看到类似git version 2.5x.x.windows.1的输出。只要能显示版本号，说明 Git 本体已经装好，PATH 也配置进去了。

接下来检查一下 Git 到底从哪个路径执行，避免你电脑上存在多个 Git 版本，后面配置混乱。Git Bash 里用：

which git

PowerShell 里用：

where.exe git

你会看到类似/c/Program Files/Git/cmd/git.exe或C:\Program Files\Git\cmd\git.exe的路径。如果指向的是你的项目目录下、或者某个奇怪路径，那就要小心了，可能是 PATH 顺序被改了。

最后再看一眼全局配置来源：

git config --list --show-origin

这个命令会列出当前生效的所有 Git 配置项，并标明每一项来自哪个文件。如果之前系统里装过旧版 Git，这里可能同时出现多个配置来源，这时候你就能知道问题出在哪个.gitconfig文件上。

2.2 PATH 环境变量的常见问题与修复

如果你的git --version提示“不是内部或外部命令”，或者 Git Bash 能打开但 CMD 里用不了，那基本就是 PATH 没配对。

按下Win + R，输入sysdm.cpl，在“高级 -> 环境变量”里找到Path这一项。用户变量和系统变量里都可能有Path，一般建议把 Git 路径加在用户变量里，避免影响到系统其他账户。

关键的路径是C:\Program Files\Git\cmd，不是C:\Program Files\Git\bin。这两个目录的区别很多人搞混：bin下面有很多 Unix 风格的工具，比如bash.exe、sh.exe，而cmd目录下才是官方提供给 Windows 命令行直接调用的入口。如果你在 PATH 里加的是bin，虽然git可能也能跑，但某些情况下会和系统自带的命令产生冲突，后期排查起来很麻烦，所以认准cmd目录。

改完 PATH 后，一定要重新打开所有终端窗口，否则环境变量不会立即生效。VS Code 如果一直开着，也要完全关闭再重开，因为 VS Code 的终端进程会继承它启动时的环境变量，光开新终端可能还是老环境。

另外一个很推荐的安装方式是winget。如果你用的是 Windows 10 以上系统，可以直接在 PowerShell 里执行：

winget install --id Git.Git -e --source winget

这种方式的优势是以后升级方便，而且它会自动把 Git 放进 PATH。同样，装完以后需要重新打开终端。

2.3 VS Code 里报“Git 未安装”时的排查顺序

VS Code 报“Git not found”是很常见的搜索话题，很多人的项目已经打开，但源代码管理面板一直提示找不到 Git。遇到这个问题，按下面顺序排查。

第一，确认系统终端里git --version是否正常。如果终端都跑不了，那 VS Code 肯定也不行，问题在 PATH 而不是 VS Code。第二，完全关闭 VS Code 再重开。这一步能解决 80% 的环境变量刷新问题。第三，如果重启后还是报错，打开 VS Code 设置，搜索git.path，手动指定 Git 可执行文件的绝对路径，例如C:\Program Files\Git\cmd\git.exe。第四，检查设置里git.enabled是否为 true。

大部分情况下，做到第二点就够了。VS Code 自己会去 PATH 里找 Git，重开后基本都能识别。真正需要手动指定路径的场景，反而多见于企业电脑、或安装了多个版本的 Git 导致路径冲突的情况。

3. 全局配置与换行符：最容易被忽略的 Windows 专属设置

3.1 身份信息：让每次 commit 都有名有姓

Git 装好不等于配置好。你第一次提交代码时，如果没有设置用户名和邮箱，Git 可能会拒绝提交，或者把提交者显示成一段奇怪的未知用户。这是因为每次 commit 都会记录作者信息，而这个信息不是从 GitHub 账号里自动读的，而是从你本地 Git 配置里读取的。

在 Git Bash 里执行：

git config --global user.name "你的名字" git config --global user.email "你的邮箱"

注意邮箱最好和你代码托管平台账号绑定的一致，这样你的提交记录才能正确关联到账号，贡献图也能正常统计。尽量不要用临时邮箱或随便编的邮箱，否则以后维护历史记录时很难追到人。

这里讲一下--global参数的含义：它表示把配置写入当前 Windows 用户下的.gitconfig文件，也就是C:\Users\你的用户名\.gitconfig。这个文件里保存了你所有 Git 全局配置。如果你希望在某个项目里用另一个身份，可以进入项目目录后不加--global再设置一次，项目内的配置会覆盖全局配置。

检查是否配置成功：

git config --global --list

你会看到刚设置的user.name和user.email。这一步只需要做一次，之后这台电脑上所有仓库都会继承。

3.2 换行符策略：核心开关 core.autocrlf

Windows 和 Linux/macOS 在文本文件的换行符上使用了不同的规格：Windows 用CRLF（回车+换行），Linux 和 macOS 用LF（换行）。如果团队里有人用 Windows、有人用 macOS，同一份代码就会反复出现“明明没改过内容，但 Git 认为整个文件都变了”的假象。

Git 为了解决这个问题，提供了core.autocrlf配置项。安装 Git for Windows 时，默认选的“Checkout Windows-style, commit Unix-style line endings”对应的就是core.autocrlf=true。这个设置的效果是：文件从仓库检出到本地时自动转成 CRLF，适合 Windows 编辑器打开；提交到仓库时自动转回 LF，保证仓库里始终是统一的 LF。

如果你的项目是纯 Windows 团队，所有成员都用 Windows，那保留true问题不大。如果你是跨平台协作，我建议在 Windows 端保留true，而 macOS/Linux 端设成input。input的含义是提交时转成 LF，检出时不做转换，这样既能保证仓库是 LF，又不会给 Unix 用户添麻烦。

通过命令设置的方式：

git config --global core.autocrlf true

还有一个需要认识的常见现象：在 Windows 上提交时，Git 经常输出warning: LF will be replaced by CRLF或反过来。这不是错误，只是 Git 在提示你它正在做换行符转换。很多新手看到 warning 就以为操作失败了，实际上提交是成功的，不要慌。

3.3 用 .gitattributes 让仓库行尾策略稳定

核心配置设置的是“本机行为”，但只要换一台电脑、换一个系统，就可能出现不同的换行符。更可靠的做法，是直接在仓库根目录放一个.gitattributes文件，把换行符策略固化到仓库里，让所有成员不管用什么系统都遵循同一套规则。

下面是我常用的一个基础模板：

* text=auto *.js text eol=lf *.ts text eol=lf *.json text eol=lf *.md text eol=lf *.bat text eol=crlf

第一行* text=auto让 Git 根据文件内容自动判断是否属于文本文件，并统一按文本处理。接下来的规则，比如*.js text eol=lf，明确指定 JavaScript 文件在仓库里和检出时都使用 LF。最后的*.bat text eol=crlf是 Windows 批处理文件的特例，因为批处理文件如果被转成 LF，在某些老版本 cmd 里可能执行异常。

添加.gitattributes之后，最好执行一次归一化操作，把仓库里已有的历史文件重新按新规则处理：

git add --renormalize . git commit -m "chore: normalize line endings"

这一步会生成一次提交，但这个提交只包含换行符变化，不包含逻辑改动。做完之后，后续合作里的换行符问题会大幅减少。这套做法是我在维护跨平台项目时最依赖的方法，比单纯设置core.autocrlf靠谱很多。

4. SSH 免密登录：从生成密钥到验证通过的完整链路

4.1 生成密钥：选 ed25519 还是 RSA 4096

SSH 免密的原理很简单：你本地生成一对密钥，一个私钥自己留着，一个公钥配置到 GitHub、GitLab、Gitee 等代码托管平台。以后 Git 通过 SSH 协议访问远程仓库时，平台用公钥验证你的身份，你的私钥证明“你是你”，整个过程不需要输入密码。

在 Git Bash 里执行下面这条命令，生成 ed25519 类型的密钥：

ssh-keygen -t ed25519 -C "you@example.com" -f ~/.ssh/id_ed25519

参数解释一下：

• -t ed25519：指定密钥类型。ed25519 是目前推荐的选择，密钥短、生成快、安全性高。
• -C "you@example.com"：给密钥加一个注释，通常填你的邮箱，方便以后在平台后台识别这把钥匙是谁的。这个注释不影响密钥功能，填错了也能用。
• -f ~/.ssh/id_ed25519：指定密钥保存的路径和文件名。~在 Git Bash 里代表你的用户目录，也就是C:\Users\你的用户名。

命令执行后，会提示你输入 passphrase（口令）。我建议设置一个，因为私钥文件落到别人手里时，没有 passphrase 对方就能直接用；有 passphrase 的话，即使文件泄露，别人也很难用。设置 passphrase 后，配合后面的 ssh-agent 操作，你平时使用并不会觉得麻烦。如果你完全无法理解这个概念，先留空也是可以的，但一定要确保私钥文件不泄露。

如果你所在的公司平台版本比较老，不支持 ed25519，那可以换成 RSA 4096：

ssh-keygen -t rsa -b 4096 -C "you@example.com" -f ~/.ssh/id_rsa

命令执行完，你的~/.ssh目录下会多出两个文件：id_ed25519是私钥，id_ed25519.pub是公钥。私钥绝对不要发给任何人，公钥则可以明文展示。

4.2 把私钥交给 ssh-agent：省掉重复输 passphrase

如果你生成密钥时设置了 passphrase，直接使用 SSH 时每次连接都要输入一次口令，很烦。解决办法是把私钥交给 ssh-agent 这个“钥匙管理员”来保管。

在 Git Bash 里执行：

eval "$(ssh-agent -s)" ssh-add ~/.ssh/id_ed25519

第一条命令启动 ssh-agent 进程，第二条命令把私钥添加进去。添加成功后会提示Identity added: /c/Users/你的用户名/.ssh/id_ed25519。之后只要这个 Git Bash 会话不关闭，你再连接远程仓库时就不会被反复问 passphrase 了。

注意一个细节：如果你在 PowerShell 里做同样的操作，可能遇到Error connecting to agent。这是因为 Windows 自带了一个 OpenSSH Authentication Agent 服务，它和 Git Bash 自带的 ssh-agent 不是同一个东西。如果你主要用 Git Bash 操作，那用上面的命令就够了。如果你希望在 PowerShell 和 VS Code 终端里都能用同一套 SSH 密钥，可以开启 Windows 的 ssh-agent 服务：

Get-Service -Name ssh-agent | Set-Service -StartupType Automatic Start-Service ssh-agent ssh-add $env:USERPROFILE\.ssh\id_ed25519

这里有个容易混的点：Git for Windows 安装时可以选择使用“自带的 OpenSSH”还是“系统 OpenSSH”。新手不用太纠结，保持安装默认即可。但如果你的ssh -T验证出现身份问题，可以检查一下：

ssh -V

看看输出的是 Git 自带的 OpenSSH 版本，还是 Windows 系统目录里的版本。多个 SSH 客户端并存时，偶尔会出现密钥文件路径或格式互相不认的情况，这时候统一使用同一个 SSH 可执行文件能减少很多麻烦。

4.3 把公钥粘贴到 GitHub/GitLab/Gitee

先查看公钥内容：

cat ~/.ssh/id_ed25519.pub

输出是一长串字符，通常以ssh-ed25519开头，后面跟着一大段 base64 编码，最后是刚才设置的注释邮箱。用鼠标从ssh-ed25519复制到结尾，不要漏掉任何字符，也不要复制出多余的空格或换行，然后去代码托管平台配置。

各平台入口大致如下：

• GitHub：右上角头像 -> Settings -> SSH and GPG keys -> New SSH key。
• GitLab：Preferences -> SSH Keys，在 Key 输入框里粘贴公钥。
• Gitee：设置 -> 安全设置 -> SSH 公钥。

粘贴时 Title 可以随便填一个能让你回忆起用途的名字，比如“Windows 笔记本 2026”。保存之后，平台会显示一个指纹，代表公钥已经生效。

这里特别提醒：GitHub、GitLab、Gitee 认的是公钥，不是私钥。公钥泄露问题不大，私钥泄露才致命。所以把公钥贴到任何平台都没有关系，但私钥文件只应该待在你自己的电脑里。

4.4 验证链路：ssh -T 成功后会看到什么

配置完公钥，验证一下整个链路是否打通。在 Git Bash 里执行：

ssh -T git@github.com

如果是 GitLab，改成：

ssh -T git@gitlab.com

首次连接时，SSH 会提示你确认远程主机的指纹：

The authenticity of host 'github.com (140.82.xx.xx)' can't be established. ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxx. Are you sure you want to continue connecting (yes/no/[fingerprint])?

输入yes并回车，SSH 会把该主机信息写入~/.ssh/known_hosts。以后连接就不会再问。

验证通过时，GitHub 会返回：

Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access.

看到这条，说明 SSH 免密已经配置成功。GitLab 返回的信息通常长这样：

Welcome to GitLab, @你的用户名!

很多人在ssh -T这一步会卡在Permission denied (publickey)。大多数人以为公钥没配好，其实更常见的坑是：agent 里没有私钥，或者当前 SSH 客户端默认读的私钥文件名不对。所以遇到报错时，按这几个顺序检查：

1. 执行ssh-add -l，看 agent 里是否加载了密钥。
2. 执行ssh -T -v git@github.com，查看详细日志，里面会显示读取了哪个私钥文件。
3. 检查平台后台的公钥是否完整粘贴，有没有多余空格。
4. 检查你实际使用的 remote URL，到底是 SSH 还是 HTTPS。

只要ssh -T成功，之后git clone git@github.com:user/repo.git这样的 SSH 地址就能免密使用了。

5. 多账号、多电脑、系统升级后的 SSH 维护经验

5.1 多平台账号的 ~/.ssh/config 配置

不少开发者会遇到这样的情况：公司用的是 GitLab 企业版，个人项目放在 GitHub 上。如果两台平台都使用默认文件名id_ed25519，那后加入 agent 的密钥可能会被当成默认私钥，导致你访问 GitHub 时 GitLab 的私钥也被尝试了一遍，结果要么认证失败，要么身份对不上。

解决办法是为不同平台生成不同的密钥文件，然后用~/.ssh/config文件按约定分发私钥。比如：

# GitHub 个人账号 Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github # 公司 GitLab Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_work

生成这两把密钥后，分别把对应的公钥配置到 GitHub 和 GitLab 后台。因为~/.ssh/config已经指定了不同域名使用不同私钥，所以即使你把两把私钥都加入 agent，Git 也会按配置选择正确的私钥，不会串号。

如果你在同一个代码托管平台有多个账号，比如两个 GitHub 账号，那就需要给Host设置别名：

Host github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work

然后用git clone git@github-work:user/repo.git来拉取仓库。Host别名会改变你在 remote URL 里看到的地址，本质上是告诉 SSH 连接github.com时用哪把钥匙。新建或修改~/.ssh/config后，不需要重启，重新打开终端就会生效。

5.2 换电脑后密钥迁移与 Windows 权限修复

换新电脑或重装系统后，很多人想把原来的 SSH 私钥直接拷贝过去。我不太推荐这种方式。更安全、也更省事的做法是：在新电脑上重新生成一对密钥，然后把新公钥添加到代码托管平台，同时删掉平台后台里旧电脑的公钥记录。这样旧私钥永远不会离开旧电脑，风险最小。

如果你确实需要迁移同一对密钥，那至少要注意两点。第一，把id_ed25519和id_ed25519.pub两个文件一起拷贝，缺一不可。第二，Windows 上的 OpenSSH 对私钥文件权限非常敏感。如果你从 U 盘或其他电脑拷贝私钥过来，双击操作、解压文件等操作都可能让私钥文件的权限包含多个用户，SSH 会直接拒绝加载，并报错：

Bad owner or permissions on C:\Users\xxx\.ssh\id_ed25519

修复方法是在 PowerShell 里执行：

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r icacls "$env:USERPROFILE\.ssh\id_ed25519" /grant:r "$($env:USERNAME):R"

第一条命令移除所有继承权限，第二条命令只给当前用户只读权限。执行完后再试ssh -T，一般就好了。这个坑很少写在官方文档里，但在 Windows 上非常常见，我至少遇到过四五次。

如果不想和权限较劲，最省心的方案还是重新生成密钥。这算不上麻烦，因为公钥重新配置一次只要一分钟，而私钥文件权限一旦搞坏，排查过程反而更浪费时间。

5.3 常见 SSH 报错对照表

把我在实际使用中遇到过的常见问题整理成一张表，方便你直接对照：

最后一种情况在企业老旧 GitLab 服务器上偶发。服务器只支持旧版 SSH 算法，而新版 OpenSSH 出于安全考虑默认关闭了这些算法，升级 Git 版本往往能解决，因为新版会兼容更多特性。如果升级后仍然不行，可能就要平台管理员更新服务端配置了。

6. HTTPS 与 SSH 不是二选一：日常使用建议

6.1 什么时候该用 SSH，什么时候用 HTTPS

很多教程会鼓吹 SSH 比 HTTPS 好，让你“必须”切换到 SSH。实际工作里，我是两者混用的。

SSH 的优势是免密、稳定、命令行体验好。一旦配置好~/.ssh/config和 ssh-agent，git push、git pull、git fetch都不会弹窗，也不依赖第三方凭据管理器。对于频繁操作命令行的人，这是最舒服的方式。

HTTPS 的优势是零配置、障碍低。你第一次克隆公共仓库时，直接git clone https://github.com/user/repo.git就能用；企业内部如果强制使用 Windows 域账号认证，HTTPS 配合 Git Credential Manager 反而比 SSH 省事。

两种方式可以随时切换。在项目目录里执行：

git remote set-url origin git@github.com:user/repo.git

这是切换到 SSH。切换回 HTTPS 则执行：

git remote set-url origin https://github.com/user/repo.git

我个人的习惯是：长期维护的项目一律用 SSH；只是临时参考、随便 clone 一下的公开项目，直接用 HTTPS，不用想密钥问题。

6.2 Git Credential Manager 与凭据清理

Windows 上使用 HTTPS 方式时，Git for Windows 默认会启用 Git Credential Manager（GCM）。第一次 push 时，它会弹出一个浏览器窗口或认证窗口让你登录平台账号，登录成功后凭据会保存到 Windows 的“凭据管理器”里。以后再用 HTTPS 访问同一个平台，就不会反复问密码。

这个机制很方便，但也有一个容易踩的坑：如果你在网页上改了平台密码，或者在平台设置里开启了双因素认证，旧凭据可能已经失效，可 GCM 仍然用旧凭据去连接，结果就是明明密码是对的，却一直报认证失败。这时候需要手动清理旧凭据：

按Win + S搜索“凭据管理器”，进入“Windows 凭据”，在“普通凭据”列表里找到 GitHub、GitLab 或git:https://github.com开头的条目，点开删除。删除后，下次 push 会重新弹出登录窗口，输入新凭据即可。

如果你从一开始就使用 SSH 免密，大概率遇不到这个问题。这也是我一直推荐身边 Windows 朋友尽早配好 SSH 的原因之一。配置完成之后，Windows 上的 Git 使用体验和 macOS、Linux 已经很接近了，剩下的就只是多写多提交、慢慢熟悉命令的问题。