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.autocrlftrue这是大多数 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 gitPowerShell 里用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.autocrlfWindows 和 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.autocrlftrue。这个设置的效果是文件从仓库检出到本地时自动转成 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文件把换行符策略固化到仓库里让所有成员不管用什么系统都遵循同一套规则。下面是我常用的一个基础模板* textauto *.js text eollf *.ts text eollf *.json text eollf *.md text eollf *.bat text eolcrlf第一行* textauto让 Git 根据文件内容自动判断是否属于文本文件并统一按文本处理。接下来的规则比如*.js text eollf明确指定 JavaScript 文件在仓库里和检出时都使用 LF。最后的*.bat text eolcrlf是 Windows 批处理文件的特例因为批处理文件如果被转成 LF在某些老版本 cmd 里可能执行异常。添加.gitattributes之后最好执行一次归一化操作把仓库里已有的历史文件重新按新规则处理git add --renormalize . git commit -m chore: normalize line endings这一步会生成一次提交但这个提交只包含换行符变化不包含逻辑改动。做完之后后续合作里的换行符问题会大幅减少。这套做法是我在维护跨平台项目时最依赖的方法比单纯设置core.autocrlf靠谱很多。4. SSH 免密登录从生成密钥到验证通过的完整链路4.1 生成密钥选 ed25519 还是 RSA 4096SSH 免密的原理很简单你本地生成一对密钥一个私钥自己留着一个公钥配置到 GitHub、GitLab、Gitee 等代码托管平台。以后 Git 通过 SSH 协议访问远程仓库时平台用公钥验证你的身份你的私钥证明“你是你”整个过程不需要输入密码。在 Git Bash 里执行下面这条命令生成 ed25519 类型的密钥ssh-keygen -t ed25519 -C youexample.com -f ~/.ssh/id_ed25519参数解释一下-t ed25519指定密钥类型。ed25519 是目前推荐的选择密钥短、生成快、安全性高。-C youexample.com给密钥加一个注释通常填你的邮箱方便以后在平台后台识别这把钥匙是谁的。这个注释不影响密钥功能填错了也能用。-f ~/.ssh/id_ed25519指定密钥保存的路径和文件名。~在 Git Bash 里代表你的用户目录也就是C:\Users\你的用户名。命令执行后会提示你输入 passphrase口令。我建议设置一个因为私钥文件落到别人手里时没有 passphrase 对方就能直接用有 passphrase 的话即使文件泄露别人也很难用。设置 passphrase 后配合后面的 ssh-agent 操作你平时使用并不会觉得麻烦。如果你完全无法理解这个概念先留空也是可以的但一定要确保私钥文件不泄露。如果你所在的公司平台版本比较老不支持 ed25519那可以换成 RSA 4096ssh-keygen -t rsa -b 4096 -C youexample.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。GitLabPreferences - SSH Keys在 Key 输入框里粘贴公钥。Gitee设置 - 安全设置 - SSH 公钥。粘贴时 Title 可以随便填一个能让你回忆起用途的名字比如“Windows 笔记本 2026”。保存之后平台会显示一个指纹代表公钥已经生效。这里特别提醒GitHub、GitLab、Gitee 认的是公钥不是私钥。公钥泄露问题不大私钥泄露才致命。所以把公钥贴到任何平台都没有关系但私钥文件只应该待在你自己的电脑里。4.4 验证链路ssh -T 成功后会看到什么配置完公钥验证一下整个链路是否打通。在 Git Bash 里执行ssh -T gitgithub.com如果是 GitLab改成ssh -T gitgitlab.com首次连接时SSH 会提示你确认远程主机的指纹The authenticity of host github.com (140.82.xx.xx) cant 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 你的用户名! Youve successfully authenticated, but GitHub does not provide shell access.看到这条说明 SSH 免密已经配置成功。GitLab 返回的信息通常长这样Welcome to GitLab, 你的用户名!很多人在ssh -T这一步会卡在Permission denied (publickey)。大多数人以为公钥没配好其实更常见的坑是agent 里没有私钥或者当前 SSH 客户端默认读的私钥文件名不对。所以遇到报错时按这几个顺序检查执行ssh-add -l看 agent 里是否加载了密钥。执行ssh -T -v gitgithub.com查看详细日志里面会显示读取了哪个私钥文件。检查平台后台的公钥是否完整粘贴有没有多余空格。检查你实际使用的 remote URL到底是 SSH 还是 HTTPS。只要ssh -T成功之后git clone gitgithub.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已经指定了不同域名使用不同私钥所以即使你把两把私钥都加入 agentGit 也会按配置选择正确的私钥不会串号。如果你在同一个代码托管平台有多个账号比如两个 GitHub 账号那就需要给Host设置别名Host github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work然后用git clone gitgithub-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 报错对照表把我在实际使用中遇到过的常见问题整理成一张表方便你直接对照报错或现象可能原因快速处理Permission denied (publickey)agent 没加载私钥或公钥未配置ssh-add -l检查再检查平台后台公钥Bad owner or permissions...私钥文件权限包含多个用户用 icacls 收紧权限只保留当前用户Could not resolve hostnameremote URL 写错域名git remote -v检查地址No such file or directory私钥路径填错用绝对路径或确认~/.ssh下文件名Connection timed out网络不通、防火墙拦截先试其他服务器排除平台本身故障Unable to negotiate...客户端与服务器算法不匹配升级 Git 版本或改用 RSA 4096最后一种情况在企业老旧 GitLab 服务器上偶发。服务器只支持旧版 SSH 算法而新版 OpenSSH 出于安全考虑默认关闭了这些算法升级 Git 版本往往能解决因为新版会兼容更多特性。如果升级后仍然不行可能就要平台管理员更新服务端配置了。6. HTTPS 与 SSH 不是二选一日常使用建议6.1 什么时候该用 SSH什么时候用 HTTPS很多教程会鼓吹 SSH 比 HTTPS 好让你“必须”切换到 SSH。实际工作里我是两者混用的。SSH 的优势是免密、稳定、命令行体验好。一旦配置好~/.ssh/config和 ssh-agentgit 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 gitgithub.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 ManagerGCM。第一次 push 时它会弹出一个浏览器窗口或认证窗口让你登录平台账号登录成功后凭据会保存到 Windows 的“凭据管理器”里。以后再用 HTTPS 访问同一个平台就不会反复问密码。这个机制很方便但也有一个容易踩的坑如果你在网页上改了平台密码或者在平台设置里开启了双因素认证旧凭据可能已经失效可 GCM 仍然用旧凭据去连接结果就是明明密码是对的却一直报认证失败。这时候需要手动清理旧凭据按Win S搜索“凭据管理器”进入“Windows 凭据”在“普通凭据”列表里找到 GitHub、GitLab 或git:https://github.com开头的条目点开删除。删除后下次 push 会重新弹出登录窗口输入新凭据即可。如果你从一开始就使用 SSH 免密大概率遇不到这个问题。这也是我一直推荐身边 Windows 朋友尽早配好 SSH 的原因之一。配置完成之后Windows 上的 Git 使用体验和 macOS、Linux 已经很接近了剩下的就只是多写多提交、慢慢熟悉命令的问题。