做开发这行久了，Git 基本已经和吃饭喝水一样普通。但每次帮同事或读者处理环境问题，Windows 上 Git 的下载、安装、环境配置、SSH 密钥这些流程，依然是问得最多的坎。很多人卡在“装是装上了，一用就报错”“每次 push 都要输密码”“密钥到底怎么生成才对”。这篇文章就是把我多年实际使用中验证过的完整流程一次讲透：从拿到安装包开始，到装完后的全局配置、SSH 密钥生成、远程平台绑定，最后再附上一份高频报错速查表。面向所有 Windows 用户，不管你用的是 Win10 还是 Win11，照着做基本都能一次通关。
1. 动手之前：先把 Windows 上的 Git 方案想清楚
1.1 先确认系统架构，避免装错版本
Git 官方针对 Windows 提供的发行版叫 Git for Windows，安装包里自带 Git Bash 终端和 Git GUI 图形界面。下载之前，第一件事是确认你的系统是 64 位还是 32 位。现在的电脑绝大多数是 64 位，但偶尔会遇到一些老机器或者 ARM 处理器的设备，装错版本虽然不一定会直接报错，但后续如果某些组件不兼容，排查起来最浪费时间。
最简单的检查方法：按Win + R输入cmd回车，在命令行里执行：
echo %PROCESSOR_ARCHITECTURE%输出AMD64就选 64 位安装包，输出x86就选 32 位。另外，Windows on ARM 的设备在官网也能找到对应的 ARM64 版本，普通用户直接装 64 位版即可。
提示：如果不确定自己的系统架构，也可以在系统设置里搜索“系统信息”，查看“系统类型”一栏。这一步做对了，后面的安装才会顺。
1.2 官网下载与可用镜像
下载地址首选 Git 官网：https://git-scm.com/downloads。页面会自动识别操作系统，点击 Windows 就能看到当前最新版本的下载入口。官网提供64-bit Git for Windows Setup和32-bit Git for Windows Setup，一般下载 64 位版就行。
如果你所在网络环境下官网下载速度不理想，也可以使用一些知名的公共镜像站，例如阿里云镜像。直接访问https://mirrors.aliyun.com/git-for-windows/，找到对应版本号的目录，下载里面的Git-x.x.x-64-bit.exe文件即可。安装包通常几十 MB，下载完成后最好先核对一下体积是否正常，太小说明文件可能没有下载完整。
这里提醒一句：尽量不要下载那些来路不明的“绿色版”“精简版”Git。我见过有人图方便用了精简版，结果缺少 Git LFS 组件，后面克隆大项目直接失败，最后还得卸掉重装。老老实实装官方完整版，是所有后续配置的基础。
2. 安装向导逐项解读：每个选项背后都有讲究
2.1 组件选择：不是全勾就完事
双击安装包，许可协议直接 Next，之后进入组件选择页面。这一屏非常关键，很多人一路默认点到底，问题就从这里埋下了。
我建议的勾选方案是：
- Additional icons —— 是否在桌面创建图标，可选可不选，属于个人喜好。
- Windows Explorer integration —— 建议勾选。它会在右键菜单里加入
Git Bash Here和Git GUI Here，实际开发中鼠标右键进入 Git Bash 是最常用也最方便的操作方式。 - Git LFS —— 建议勾选。如果团队里有人使用 Git LFS 管理大文件，你没有这个组件，clone 大仓库时会提示缺少工具。
- Associate .git configuration files —— 建议勾选。双击
.gitconfig文件时可以直接关联到 Git 配置工具，对后面对环境配置有好处。 - Associate .sh files to be run with Bash —— 建议勾选。Windows 上双击
.sh脚本会用 Bash 来执行，免去了手动选择打开方式的麻烦。 - Use a TrueType font in all console windows —— 建议勾选。这个选项会改善命令行里的字体显示效果，中文和特殊符号不容易乱。
2.2 默认编辑器、PATH、SSH 后端，三个最重要的选择
进入下一步后，第一个大项是选择 Git 的默认编辑器。默认选项是 Vim，老工程师可能觉得无所谓，但一个刚接触命令行的新手如果不小心在git commit时进入 Vim 界面，出来会遇到“到底怎么退出”的问题。编辑器这里我建议直接选你已经装了并且熟悉的编辑器，比如 VS Code、Notepad++，或者 Sublime Text。如果你一个外部编辑器都没装，就先保留 Vim，同时在本文后面记住一个操作：在 Vim 里按Esc，输入:wq保存退出，输入:q!不保存强制退出。
接着是调整 PATH 环境变量，这一项选择错误会让你在 PowerShell 或 cmd 里怎么都敲不出git命令。三个选项的区别我实际解释一下：
- 第一项：仅从 Git Bash 使用 Git。选了之后，
git命令只在 Git Bash 里能用，PowerShell 和 cmd 都识别不了。适用于系统里已经有别版本 Git 的少数场景。 - 第二项：从命令行以及第三方软件使用 Git。这是最推荐的一项。它会自动把 Git 的
cmd目录加进系统 PATH，PowerShell、cmd、VS Code、JetBrains 系列 IDE 都能直接调用git。 - 第三项：从命令提示符使用 Git 和相关 Unix 工具。不仅加入 Git，还会把
bash、ls、find等 Unix 工具覆盖进系统路径。我建议普通用户不要选这一项，因为会和 Windows 自带的find.exe等命令产生冲突。
然后是 SSH 可执行文件页。这里问的是“使用哪个 SSH 客户端”：第一个是 Git 自带的 OpenSSH，第二个是系统 Windows OpenSSH。我建议选第一个，即 Git 自带的 OpenSSH。原因是版本与 Git 集成度更好，而且在 Git Bash 里使用ssh-keygen、ssh-agent等命令时行为一致，不容易出现密钥路径识别不了的问题。
注意：如果选“使用系统 OpenSSH”，在 Git Bash 里执行
ssh-keygen时，调用的是C:\Windows\System32\OpenSSH\ssh-keygen.exe，密钥和代理服务可能与 Git 自带的不一致，新手容易绕晕。
2.3 HTTPS 证书后端、换行符转换与终端模拟器
安装向导继续往下会问 HTTPS 传输后端，默认是 OpenSSL 库，另一项是 Windows 内置安全通道（Secure Channel）。绝大多数用户保持默认 OpenSSL 即可。只有在企业内部网络使用自签名证书，并且已经在 Windows 证书库里导入过自己公司证书的场景下，选 Windows 内置安全通道会更省心。个人开发者完全不用纠结这里，用默认值就好。
换行符处理这一项，是 Windows 下 Git 最容易引发困惑的设置。三种选项分别是：
- 检出 Windows 风格，提交 Unix 风格的行尾符。
- 按原样检出，按原样提交。
- 检出 Unix 风格，提交 Unix 风格的行尾符。
我推荐第一项。原因是 Windows 下的许多旧工具和部分文本编辑器对LF（Unix 换行）支持不佳，第一项会在你把文件从仓库里“检出”到本地时自动转成CRLF（Windows 换行），保存文件后“提交”时又自动转回LF，远程仓库里始终是纯LF，团队里用 Windows、macOS、Linux 的同事都不会被换行符污染。如果你的团队已经全部统一用 LF，那么第三项也合理，但要注意未跟踪文件和已有文件可能因为行尾不一致导致整个文件 diff 变红。对新手来说，第一项是最稳妥的。
接下来是终端模拟器选择，推荐第一项 MinTTY。它比 Windows 默认控制台窗口好用不少，支持中文更正常，快捷键、复制粘贴交互也更友好，命令行体验与 Linux 终端更接近。第二项是 Windows 自带的控制台窗口（conhost），如果你习惯了 cmd 的操作方式，选它也完全能用，但对大多数新手，MinTTY 的学习成本更低。
2.4 pull 行为、凭证管理器与杂项配置
git pull的默认行为有 merge 和 rebase 两个选项。默认是 merge，新手建议保留默认。merge 的操作方式更容易理解，分支历史虽然会有分叉节点，但不会破坏已有提交。如果你已经熟悉 rebase 工作流，可以改成 rebase，让提交历史更线性化。这个设置后续也可以用git config --global pull.rebase true/false随时调整，所以安装时不用太焦虑。
凭证管理器那里，默认勾选了 Git Credential Manager（GCM）。这个组件建议一定要保留，它有图形界面弹窗，会帮你记住 HTTPS 协议的账号或访问令牌，避免在命令行里反复输入 GitHub、GitLab 的密码。后面我会在 SSH 方案里另外讲，这里留个印象。
最后的附加配置里，文件系统缓存的勾选保留即可，这项能提升文件状态检查速度；符号链接在 Windows 下默认不推荐勾选，因为创建符号链接需要额外权限，普通用户勾了之后反而会出现奇怪的问题，保持默认关闭就好。
2.5 安装完成后的第一眼检查
等待进度条走完，安装成功的标志是桌面或文件夹右键菜单里出现了Git Bash Here和Git GUI Here。如果菜单里看不到，可能是右键菜单项注册失败，重启一次资源管理器通常能解决。
打开 Git Bash，执行：
git --version看到类似git version 2.x.x.windows.x的输出，就说明安装核心部分已经完成。如果这一步报“找不到命令”，基本可以确认在 PATH 选择那一步选了第一项，回头重装一次，或者按我第 5 部分的方法手动补环境变量即可。
3. 环境配置与基线设置：装完不乱才行
3.1 命令行入口：Git Bash、Git CMD、PowerShell 怎么选
Git 装完后，Windows 上会有多个入口。我最推荐日常开发使用 Git Bash，因为它的命令风格贴近 Linux 环境，ls、grep、ssh、vim这些工具都有，并且路径会转换为/c/Users/你的用户名这样的形式，在写脚本和命令时比 Windows 路径少很多转义问题。
Git CMD 是让习惯 cmd 的人使用的入口，功能上没区别，但它没有 Bash 语法环境。PowerShell 用户则直接打开终端执行git，前提是你安装时 PATH 选的是第二项。我个人的习惯是：在 IDE 里用集成终端操作 Git，在独立工程项目里直接用 Git Bash。看你自己习惯，工具本身不冲突，重点是把基础配置做对。
3.2 身份信息配置：user.name、user.email 绕不开
Git 每次提交文件时都会记录提交人信息，这个信息不是从系统账号里读取的，而是读取你配置的user.name和user.email。如果不配置，第一次 commit 时 Git 会报错提示你补上。
配置命令如下：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"注意两点。第一，--global表示当前用户全局生效，如果不加，就只对当前仓库生效。第二，user.email建议与你在 GitHub、GitLab 等平台的账号邮箱保持一致。拿 GitHub 举例，提交记录通过邮箱关联到你的账号，头像和 contribution 热力图才会正确显示。邮箱不一致的话，提交虽然成功，但在网站上不会归到你的用户名下，后面想改历史记录很麻烦。
3.3 高频全局配置清单：一次设好，省心很久
身份信息只是第一步。以下这些是我实际使用中验证过的高频全局配置，建议手动执行一遍。
# 新仓库默认分支名设为 main git config --global init.defaultBranch main # 如果你安装时选了 CRLF 转换，这里保持默认即可，可再确认一下 git config --global core.autocrlf true # 让中文文件名在 git status 里正常显示，而不是显示成八进制转义 git config --global core.quotepath false # 让 Git 追踪文件名大小写变化（Windows 文件系统默认不区分大小写） git config --global core.ignorecase false # 凭证管理，记住 HTTPS 凭据 git config --global credential.helper manager # 查看所有配置 git config --global --listcore.quotepath false是非常实用的一个配置。Windows 上如果你的仓库里有中文文件名，不做这个设置，执行git status时会看到类似"\346\265\213\350\257\225.txt"这种乱码字符串。设置之后，中文正常显示。core.ignorecase也很关键，Windows 文件系统对大小写不敏感，但 Git 内部是敏感的，如果你把Readme.md改成README.md，不设置这一项，Git 可能完全察觉不到变化。
3.4 把配置沉淀成自己的 .gitconfig
所有全局配置最终都会写入用户目录下的.gitconfig文件。Windows 下它的位置是C:\Users\你的用户名\.gitconfig。这个文件是纯文本，你完全可以手动编辑。我贴一份常见的模板：
[user] name = Your Name email = your@example.com [core] autocrlf = true quotepath = false ignorecase = false editor = code --wait [init] defaultBranch = main [pull] rebase = false [credential] helper = manager [diff] tool = vscode文件里的core.editor如果设置为code --wait，表示默认编辑器用 VS Code，并且在git commit时等待 VS Code 窗口关闭才继续执行。注意一点：如果要用这个配置，得保证 VS Code 的code命令已经加入了 PATH。在 VS Code 里按Ctrl+Shift+P，输入Shell Command: Install 'code' command in PATH执行一次就能搞定。
4. SSH 密钥从零到一：Git 远程连接的完整闭环
4.1 为什么值得用 SSH 而不是 HTTPS
clone 远程仓库一般有两种协议：HTTPS 和 SSH。HTTPS 配置简单，但每次 push 要么输密码，要么依赖凭证管理器弹窗，如果账号开了二次验证，还要用 Personal Access Token 代替密码，刚上手的人很容易在这里卡住。SSH 协议的核心思路是配置一次密钥，后续 push、pull 都不需要输密码。
原理其实不复杂：密钥是一对文件，一个公钥、一个私钥。公钥放到远程代码平台（GitHub、GitLab、Gitee 都有对应入口），私钥自己保存在本机。连接时，远程平台通过密码学握手确认你的私钥确实匹配公钥，验证通过就直接放行。这就像你给自己家配了一把钥匙，门锁（公钥）装在服务器上，自己手里留了一把钥匙（私钥），只要钥匙对应，门就能开。
4.2 生成密钥前先检查是否已有存量密钥
执行下面命令查看当前用户目录下有没有已经生成的密钥：
ls -al ~/.ssh如果看到id_ed25519和id_ed25519.pub，或者id_rsa和id_rsa.pub，说明你之前生成过密钥。这时你可以考虑直接复用旧密钥，把对应的.pub公钥内容添加到新平台即可；如果不放心旧密钥的安全性，也可以重新生成，然后用新公钥替换各平台的记录。
4.3 用 ssh-keygen 生成第一把密钥
在 Git Bash 里执行生成命令：
ssh-keygen -t ed25519 -C "your_email@example.com"-t ed25519指定密钥类型，Ed25519 是目前在签名速度和安全性上都很均衡的算法，支持它的平台也越来越普遍。如果你的远程服务器或 Git 服务版本比较老，兼容性有问题，再改用 RSA：
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"执行后会提示你确认保存路径，默认是~/.ssh/id_ed25519，直接回车用默认即可。接着会让你设置 passphrase（口令）。这一步很多人拿不准要不要填。我的建议是：在个人电脑上如果不怕麻烦，设置一个口令安全性更好，即使私钥文件泄露，别人也解密不了；当然，口令会在每次使用密钥时被要求输入，为了不烦人，可以配置 ssh-agent 在会话中帮你记住口令。如果你图省事，直接留空也是可以的，但私钥文件一旦泄露就等于裸奔。
生成完成后，.ssh目录下会出现两个文件：id_ed25519是私钥，留在本机绝对不要发给任何人；id_ed25519.pub是公钥，可以放心添加到各远程平台。
4.4 添加公钥到 GitHub、GitLab、Gitee
查看公钥内容可以用：
cat ~/.ssh/id_ed25519.pub更高效的方法是直接把内容复制到剪贴板：
clip < ~/.ssh/id_ed25519.pub执行完clip命令后，Ctrl+V就能把公钥粘贴到任意位置。然后登录你的代码托管平台，找到 SSH keys 的设置入口：
- GitHub：右上角头像 -> Settings -> SSH and GPG keys -> New SSH key。
- GitLab：点击头像 -> Edit Profile -> SSH Keys。
- Gitee：头像 -> 设置 -> SSH 公钥。
把公钥内容粘贴到 Key 输入框，Title 随便写一个便于识别的名字，比如my-windows-laptop，保存即可。这里有个小细节：粘贴时注意前后不要有多余空格，很多失败案例是复制时把换行符也一起粘进去了。
4.5 启动 ssh-agent 并验证连接
ssh-agent 是一个帮你管理私钥、避免每次使用都输入 passphrase 的后台服务。在 Git Bash 里启动：
eval "$(ssh-agent -s)"然后添加私钥：
ssh-add ~/.ssh/id_ed25519如果你设置了 passphrase，此时会要求输入一次，后续这个终端会话内就不需要重复输入了。
验证到 GitHub 的连接：
ssh -T git@github.com首次连接会出现一条确认主机指纹的提示，输入yes回车，看到类似Hi 你的用户名! You've successfully authenticated, but GitHub does not provide shell access.的信息，就说明密钥配置全程已打通。Gitee 的验证命令是ssh -T git@gitee.com，GitLab 则把域名替换成你实际使用的地址。
4.6 多平台多账号时，用 config 文件隔离密钥
如果你有多个代码平台的账号，或者一台电脑上要用两套不同的密钥，比如一套 GitHub 个人项目用，一套公司 GitLab 用，直接把不同密钥都加到远程平台后，Git 连接时用的是默认的id_ed25519，你会发现另一个账号连接不上。
解决办法是在~/.ssh/config文件里写清楚规则：
# GitHub 个人账号 Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal # GitLab 公司账号 Host gitlab.company.com HostName gitlab.company.com User git IdentityFile ~/.ssh/id_ed25519_work配置后执行ssh -T git@github.com，Git 会根据 Host 里写的域名自动选择对应的私钥，两个平台切换互不干扰。这个文件可以手动创建，注意不要加多余空格，否则可能解析失败。
5. 高频问题与解决实录：这些都是真实踩过的坑
5.1 “git 不是内部或外部命令”
这基本是 PATH 选择不对导致的。安装完成后在 cmd 里执行git，如果提示命令找不到，说明 Git 的cmd目录没有加入系统 PATH。解决办法有两个：
- 重新运行安装程序，选择 Modify，把 PATH 选项改成第二项。
- 手动补环境变量：右键“此电脑” -> 属性 -> 高级系统设置 -> 环境变量，编辑用户变量的
Path，新增C:\Program Files\Git\cmd，然后重启终端。
需要注意，修改环境变量后要新开终端窗口才会生效，在旧窗口里执行永远看不到变化。
5.2 老是提示输入用户名密码，或者 Permission denied
先判断自己 clone 时用的是 HTTPS 还是 SSH。如果远程地址是https://github.com/...，那每次 push 提示输入用户名密码是正常的。解决思路要么配置凭证管理器让它记住：
git config --global credential.helper manager要么改用 SSH 方式连接，把 remote 远程地址改成 SSH：
git remote set-url origin git@github.com:用户名/仓库名.git如果提示的是Permission denied (publickey)，优先检查三件事：一是确认公钥已经加到平台；二是确认ssh-add -l能看到你的私钥；三是用ssh -vT git@github.com输出详细日志，看是哪一步失败，这一步能清晰看出 Git 实际尝试的密钥文件是哪个。
5.3 中文文件名乱码、status 里全是奇怪符号
这个问题十有八九是core.quotepath没有设置。执行：
git config --global core.quotepath false然后再看git status，中文文件名就正常了。如果终端本身乱码，还要确认 Git Bash 的语言环境，可以在 Git Bash 里执行echo $LANG，正常应该输出zh_CN.UTF-8或en_US.UTF-8。
5.4 换行符引起的整个文件 diff 全红
场景是这样的：你在 Windows 上改了文件，提交时发现 diff 里整个文件都变了，哪怕只改了一行。这是core.autocrlf不一致导致的。如果本地配置是false，仓库里原本是 LF，你编辑时某次保存成了 CRLF，Git 就认为整个文件的所有行都被修改了。
处理办法是统一配置：
git config --global core.autocrlf true假如仓库已经混入了一堆 CRLF，需要重新规范化行尾，可以在仓库根目录执行：
git add --renormalize . git add -u git commit -m "normalize line endings"更规范的做法是在仓库根目录添加.gitattributes文件，显式声明文本文件统一使用 LF：
* text=auto *.js text eol=lf *.md text eol=lf有了这个文件，所有开发者不管在什么系统上，检出和提交行为都会被 Git 强制统一，从根上避免换行符问题。
5.5 其他几个容易忽略的小问题
Git Bash 里打开 VS Code 提示找不到命令，先检查是否执行过Shell Command: Install 'code' command in PATH。Windows 自带的 OpenSSH 服务和 Git 自带 SSH 冲突时，优先保持一种 SSH 工具链，别混用。杀毒软件偶尔会拦截 Git 的安装进程，遇到安装中断，先关闭实时监控再重试。另外，安装路径不要放在带中文或空格的目录下，默认路径C:\Program Files\Git没有中文，是最稳的。
这几个问题都是我在实际使用中碰过壁的，尤其换行符那个，曾经在一个团队项目里导致大量无效 diff，最后靠.gitattributes才彻底解决。如果你也遇到类似情况，别慌，按上面的步骤一步步检查基本都能恢复。
最后再分享一个我个人的习惯：SSH 私钥在我看来和银行卡密码是同一个级别的敏感信息，所以我会给私钥设置 passphrase，并且在换电脑时只迁移公钥到新平台，私钥通过加密导出而不是直接明文拷贝。配置好之后，我通常会在新环境里先完整走一遍ssh-keygen、启动 ssh-agent、ssh -T git@github.com验证连接全流程，确认无误后再开始克隆项目。这套方法虽然前期多花几分钟，但后面每次 push、pull 都顺畅得多，值得养成习惯。
