Windows 下 Git 安装配置与 SSH 密钥设置完整指南

说实话，我见过太多新手卡在 Git 这一步——下载完了不知道选什么选项，安装好了不知道怎么配置，想用 SSH 又觉得密钥那套东西玄乎得很。这篇文章我把自己在 Windows 上从零装 Git、配环境、折腾 SSH 密钥的完整流程给你讲透，照着走一遍基本不会出问题。无论你是刚接触版本控制的学生，还是需要和团队协作的前端、后端、测试同学，这篇教程都适用，而且所有操作我都基于 2026 年当前最新稳定版重新验证过。

很多人觉得 Git 就是"装个软件，点下一步"，实际用起来才发现坑都在后面：换行符报错、提交记录里作者信息不对、Push 一次输一次密码、VSCode 连不上远程仓库……这些问题归根结底是安装阶段选项选错、环境配置没做到位、SSH 密钥没有正确生成。下面我按实际操作的顺序，完整走一遍。

1. 下载安装：这些选项别闭着眼睛点

1.1 版本选择与下载渠道

去官网下载 Git for Windows，认准git-scm.com/download/win，一般会自动识别系统架构并开始下载。如果你的浏览器没自动下载，也可以手动选择 64-bit 或 32-bit 版本——现在绝大多数电脑都是 64 位，选64-bit Git for Windows Setup即可。

这里多说一句：千万不要在第三方下载站下载"高速版""一键安装版"Git，一是可能捆绑流氓软件，二是版本往往滞后而且没经过官方校验。Git 官网下载速度虽然不算快，但胜在安全可靠。如果你在公司网络环境下载困难，也可以使用国内高校或开源镜像站下载安装包，原理是一样的，自行核对 SHA-256 校验值即可。

安装包命名通常是Git-2.5x.x-64-bit.exe这种格式，双击运行之前，建议先把所有正在运行的编辑器、IDE 关掉，避免安装过程中文件占用导致组件安装失败。

1.2 安装向导关键选项逐项拆解

启动安装向导后，大部分界面可以按默认配置，但有三个位置必须分清，直接影响后续使用体验：

• 选择安装组件（Select Components）:这里的默认选项基本够用。重点确认Git Bash Here和Git GUI Here这两项一定要勾选，它们决定了你在文件夹右键菜单里能不能直接打开 Git 终端。其他的如Scalar、Git LFS等辅助组件建议保留默认，Git LFS在大文件场景很实用，即使现在用不上，保留也无妨。

• 默认编辑器（Default editor）：这里默认是 Vim。如果你不熟悉 Vim，以后执行 commit 命令进入编辑页面时会非常崩溃（不知道怎么保存退出）。建议直接选Use Visual Studio Code as Git's default editor，前提是机器上装了 VSCode；没装就选Use Notepad++或者干脆继续用 Vim，后面通过命令也能改，这里不用太纠结。

• 调整 PATH 环境变量（Adjusting your PATH）：这是最关键的一步。务必选第二项Git from the command line and also from 3rd-party software。选第一项，Git 只有自带的 Git Bash 能用，你在 CMD、PowerShell、VSCode 终端里敲git会直接提示"不是内部或外部命令"；选第三项则会把很多 Unix 命令（如find、sort）注入系统，容易和其他软件冲突。

我还遇到过有人安装完 Git，打开 CMD 里输git能识别，但一打开 VSCode 终端就报错——这种多半是因为安装时 PATH 选项选错，或者安装后新开的软件继承了旧环境变量，重启一下软件甚至重启系统就能解决。

1.3 安装过程中容易忽略的几个细节

继续往后走还有几个选项值得留意:

• HTTPS 传输后端：默认用OpenSSL即可，国内访问 GitHub 即使偶尔不太稳定，也跟这个选择没关系，不用动。
• 换行符转换（Line ending conversions）：默认第一项Checkout Windows-style, commit Unix-style line endings。这是比较稳的一种方案，Windows 下检出自动转成 CRLF，提交到仓库时转回 LF，减少跨平台协作的换行符问题。关于换行符更细的说明，我在 2.2 节还会展开。
• 终端模拟器：默认MinTTY就行，显示效果更好；想彻底跟 Windows 控制台保持一致风格就选Windows Console，一般不用改。
• 额外选项里Enable file system caching、Enable Git Credential Manager都建议保持勾选。Credential Manager 就是你以后走 HTTPS 方式 Push 时只需登录一次、之后自动记住凭证的组件，非常实用。

安装完成后，在任意文件夹里右键，菜单里应该能看到Open Git Bash here。如果没看到，重新运行安装包，选择 Modify，确保组件勾选完整。

2. 基础环境配置：改掉默认的"新手三件事"

2.1 验证安装并定位 Git 目录

安装完先做个验证。打开 CMD 或 PowerShell，输入：

git --version

能输出版本号（比如git version 2.5x.x.windows.1）说明安装成功。如果提示找不到命令，优先检查 PATH 里有没有C:\Program Files\Git\cmd，没有就手动加上，或者检查一下刚才是不是选了第一项Use Git from Git Bash only，这种情况直接把安装目录下的cmd目录加到系统环境变量即可。

验证环境的同时，我建议你顺手确认一下 Git 的安装路径和全局配置路径。运行：

git config --list --show-origin

这个命令能列出所有生效的配置项以及它们来自哪个文件（系统级、全局级、仓库级），排查问题时特别有用。默认情况下，全局配置在C:\Users\你的用户名\.gitconfig，后面手动编辑配置也经常会用到它。

2.2 配置用户信息：提交记录的身份标识

每次提交代码都会记录作者信息，而这个信息来自 Git 的user.name和user.email配置。不配置的话，虽然也能提交，但提交记录会显示成unknownauthor之类的乱码，代码评审和团队协作时很难定位是谁改的。

打开 Git Bash 或终端，执行：

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

这里的邮箱建议填你 GitHub/Gitee 等平台账号绑定的邮箱，这样提交记录才能关联到你的账号头像。--global表示对当前 Windows 用户全局生效，后续所有仓库都会复用这组配置。

配置完之后可以查看效果：

git config --global --list

如果你在不同仓库需要不同身份（比如公司仓库用一个、私人仓库用另一个），可以去掉--global，进入对应仓库目录里单独设置：

git config user.name "公司花名" git config user.email "公司邮箱"

这样仓库级别的配置会覆盖全局配置，够灵活。

2.3 换行符问题：Windows 和 Unix 的隐形冲突

Windows 的文本文件行尾是CRLF（回车+换行），Linux/Mac 是LF（换行）。如果一个项目里两种行尾混着来，Git 会经常提示"文件已修改"但实际上内容没变，极其影响使用体验。

安装时默认选的Checkout Windows-style, commit Unix-style line endings基本能解决大半问题。但保险起见，我建议在全局配置里明确加一条规范：

git config --global core.autocrlf true

core.autocrlf true的含义是检出版本库文件时把 LF 转成 CRLF（适配 Windows 工具），提交时把 CRLF 转回 LF（保证仓库里统一存 LF）。如果团队项目已有.gitattributes文件（里面声明了哪些文件用 LF、哪些用 CRLF），core.autocrlf的自动化转换就会被文件级规则覆盖，此时就不需要额外配置。简单说，个人开发、Windows 单场景用true最省心；跨平台团队项目，严格遵守.gitattributes约定即可。如果你写的是 shell 脚本或 Python 脚本，且明确希望仓库和本地都保持 LF，可以设置：

git config --global core.autocrlf input

这种方式不会在检出时强制转 CRLF，推送时只负责转 LF。总之别用false，除非你非常清楚自己在做什么——false意味着 Git 完全不管行尾转换，跨平台协作必出问题。

2.4 常用体验优化配置

配置好身份和换行符，Git 基本能正常用了，但为了让日常操作更顺手，我推荐追加这几条优化项：

# 开启彩色显示，git status/diff 输出更直观 git config --global color.ui true # 常用别名，少敲几个字母 git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.st status git config --global alias.lg "log --oneline --graph --all -10" # 配置默认编辑器为 VSCode（没有装就忽略） git config --global core.editor "code --wait" # 配置大小写敏感，避免 Windows 默认忽略文件名大小写导致的问题 git config --global core.ignorecase false

配置完别名后，git st就是git status，git lg能以图形简化模式看提交历史，体验提升非常明显。如果以后想修改某个配置，重复执行上面命令即可，后面会直接覆盖前面。想取消某个配置，用git config --global --unset 配置项名就行。

需要提醒的是core.ignorecase false只对之后的新仓库生效，已经存在的仓库想改大小写，需要单独处理（重命名文件分两步走或者用git mv），这里不展开，但至少从源头避免踩坑。

3. SSH 密钥生成与配置：彻底告别每次输密码

3.1 为什么是 SSH 而不是 HTTPS

本地 Git 和远程仓库（GitHub、Gitee、GitLab 等）通信有两种主流方式：HTTPS 和 SSH。

• HTTPS：初次 Push 时输入用户名和密码（或令牌），后续靠 Windows 凭据管理器自动记住，配置简单，但每次在新电脑上都要重新登录一次，而且某些环境下还要处理令牌过期问题。
• SSH：本地生成一对密钥（公钥+私钥），把公钥放到远程平台，本地通过私钥完成身份验证。配置好后，Push/Pull/Clone 全程不输任何密码，也不需要处理令牌过期问题，多机环境下尤其方便。

我自己的习惯是：公司电脑和私人电脑全走 SSH，一次性配置，长期免登录。唯一的代价是首次生成密钥和配置的过程大概多花五分钟，但换来的是后面几年的安逸，非常划算。

3.2 生成密钥：选对算法和邮箱

打开 Git Bash，执行：

ssh-keygen -t ed25519 -C "你的邮箱"

这里我推荐ed25519算法，它生成的密钥更短、安全性更高、验证速度也快。如果你的服务商不支持 ed25519（一些老旧的内部 Git 平台确实只支持 RSA），再用传统 RSA 算法：

ssh-keygen -t rsa -b 4096 -C "你的邮箱"

执行命令后，命令行会提示保存路径，直接回车使用默认路径C:\Users\你的用户名\.ssh\id_ed25519即可。接着会提示设置 passphrase（口令短语），这是给私钥再上一道锁，建议设置一个你记得住的短语。这样即使私钥文件被拷走，没有短语也解不开。

设置 passphrase 之后，每次新开终端第一次使用密钥时可能要求输入一次短语。如果你觉得麻烦，可以在生成密钥时不输入任何内容直接回车（也就是 passphrase 为空），安全性略降但便利性拉满。我的建议是至少在常用电脑上设置 passphrase，并配合系统凭据管理器缓存，日常体验几乎没有额外负担。

生成完成后，~/.ssh目录会多出两个文件，id_ed25519是私钥，id_ed25519.pub是公钥。私钥绝对不能泄露，公钥随便给别人看。

3.3 添加公钥到远程仓库平台

查看公钥内容：

cat ~/.ssh/id_ed25519.pub

复制输出的整行内容（以ssh-ed25519或ssh-rsa开头、以你邮箱结尾的一长串字符）。然后按你使用的平台操作：

• GitHub：Settings → SSH and GPG keys → New SSH key → 粘贴公钥 → Add SSH key。
• Gitee：设置 → SSH 公钥 → 粘贴公钥 → 保存。
• GitLab：Preferences → SSH Keys → 粘贴公钥 → Add key。

这里有个经验：平台生成公钥后，建议给公钥取一个有识别度的标题，比如ThinkPad-Windows-Work、DESKTOP-HOME，这样以后在平台管理密钥时能一眼看出是哪台机器的，尤其多设备用户会感谢这个习惯。

3.4 测试连接与常见失败点

配置完成后，在 Git Bash 里执行：

ssh -T [e-mail]

如果连的是 Gitee：

ssh -T [e-mail]

首次连接会询问你是否信任该主机的指纹（fingerprint），输入yes回车确认即可。验证成功的标志是一段欢迎信息，比如 GitHub 会显示Hi 用户名! You've successfully authenticated, but GitHub does not provide shell access.。

测试失败的原因九成是以下几种：

• 公钥确实没配好：回到 3.3 重新检查粘贴的公钥是否完整、有没有多余空格。
• SSH 客户端读不到私钥：确认生成的密钥路径在~/.ssh下，且文件名是默认的。如果你换了路径或者改了名，Git 找不到文件自然验证失败。
• 使用了多把密钥但默认加载了错误的私钥：Windows 上可以通过编辑~/.ssh/config文件指定某个域名使用某把密钥，这个文件按文本格式创建即可，示例写法如下：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519

• 公司网络屏蔽了 SSH 的 22 端口：可以尝试改用 443 端口连接 GitHub，但这是进阶操作，遇到再具体解决。

3.5 关联 remote 仓库并验证

把远程仓库地址改成 SSH 格式。命令行下先查看当前仓库的远程地址：

git remote -v

示例里形如https://github.com/用户名/仓库.git的是 HTTPS 地址，改成 SSH 地址：

git remote set-url origin [e-mail]:用户名/仓库.git

然后测试拉取或直接推送一次，整个过程不再提示输入账号密码，配置就算真正生效了。从平台页面点击Code按钮选择SSH标签，也能拿到对应的 SSH 格式地址。

4. 常见问题排查与操作实录

4.1 git 命令找不到

新装 Git 之后，CMD 和 PowerShell 里输入git提示"不是内部或外部命令"，这种问题通常由两类原因导致：

• 安装时 PATH 选项选了第一项（Git Bash only），环境变量里没有 Git 路径。修复方法：打开系统环境变量编辑界面，在Path里新增一行C:\Program Files\Git\cmd，保存后重开终端。
• 系统环境变量改了但当前终端没刷新。Windows 下环境变量改动后，已经打开的终端不会自动同步，要新开一个 CMD 窗口，或者直接注销重登。

排查看是不是安装路径在 D 盘或者自定义目录，这种情况把 Path 改成你自己的实际安装目录即可。

4.2 频繁出现"LF will be replaced by CRLF"警告

很多人第一次运行git add时看到一行warning: LF will be replaced by CRLF，慌了，担心文件内容被改。其实这只是 Git 在执行换行符转换时给你的提示信息，不影响提交内容。

如果你希望警告消失，按 2.3 节里的方法设置core.autocrlf true后再git add就不会反复提示了。更进一步的团队级方案是提交一个.gitattributes文件，在文件里明确声明各类文件的换行符规则，比如：

* text=auto *.sh text eol=lf *.bat text eol=crlf

这样全团队统一规则，换行符问题从根源上解决，提交记录也会更干净。

4.3 SSH 密钥认证失败：Permission denied (publickey)

执行ssh -T [e-mail]时如果收到Permission denied (publickey)，按顺序排查：

1. 确认公钥是否已经添加到远程平台，这个过程是否完整。
2. 确认本地~/.ssh文件夹下有没有正确的私钥文件。
3. 如果生成密钥的时候指定了非默认文件名，需要在~/.ssh/config文件里显式声明IdentityFile路径，或者把密钥文件重命名为默认的id_ed25519、id_rsa。
4. 如果你正在使用 VSCode 连接远程服务器，且这台远程服务器要访问 GitHub，密钥要部署在远程服务器上（authorized_keys），不是 Windows 本机。很多人在这一步搞混，以为本机配好就行，实际上"哪台机器发起 Git 操作，密钥就配置在哪台机器/哪个用户目录下"。

4.4 Git 提示输入密码但密码总不对

如果你走的是 HTTPS 方式推送，而平台账号已经改成令牌（Token）或二步验证，Git 弹出的密码框输入账号密码自然会失败。解决办法是：

• 使用个人访问令牌（Personal Access Token）代替密码输入，令牌平台后台均可生成。
• 或者干脆切换到 SSH 方式，按第 3 节的流程走完，就没有密码问题了。

Windows 下如果 Git 凭据管理器里保存了旧的账号密码，切换令牌后也建议去"控制面板 → 用户账户 → 凭据管理器 → Windows 凭据"里找到 Git 相关条目删掉，否则可能一直用旧凭据重试导致认证失败。

4.5 多账号需要切换 SSH 密钥

如果你同时用两个 GitHub 账号（工作+个人），或者 GitHub 和 GitLab 都要用不同密钥，运维思路就是通过~/.ssh/config给不同域名指定不同IdentityFile。示例：

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

这样配置后，工作相关的仓库 remote 地址写git@github-work:工作用户名/仓库.git，个人仓库写git@github-personal:个人用户名/仓库.git。Git 会依据 Host 别名选择对应的私钥文件，避免"一把钥匙只能开一个锁"的麻烦。

4.6 其他零碎的坑

还有一个常见问题是git status中文文件名显示成八进制转义字符（类似"\346\265\213\350\257\225.txt"），解决办法是设置：

git config --global core.quotepath false

这样中文文件名就能正常显示。另外如果你用 VSCode 写代码并集成了终端，建议在 VSCode 的默认终端里选 Git Bash 作为 shell，这样在编辑器里跑 Git 命令跟 IDE 底层的 Git 插件行为一致，能少很多困惑。

5. 操作验证与日常养护

完成以上所有配置后，我习惯新建一个测试仓库做一次完整的"冒烟测试"：git init→ 新建一个文件 →git add→git commit→ 关联远程仓库（SSH 地址） →git push→ 改动 →git pull。全套流程走通，说明 Git 的下载、安装、环境配置、SSH 密钥这四个环节全部工作正常。

日常使用中，偶尔会遇到 Git 配置被软件改乱的情况，比如某些 IDE 自动创建了仓库级配置覆盖了全局配置。这时用git config --list --show-origin查看当前仓库下所有配置的来源，逐项排查就很快。另外一个好习惯是定期清理本地的分支和远程跟踪分支，养成分支命名规范（比如feature/xxx、bugfix/xxx），这虽然不属于安装配置的范畴，但对长期使用体验的提升立竿见影。

最后分享一个我个人的小经验：新电脑拿到手，第一件事不是装各种编辑器，而是先把 Git 和 SSH 密钥配置好。因为所有代码拉取、环境搭建、配置同步几乎都离不开 Git。把基础打稳，后面不管是前端、后端、运维还是算法方向，都能少很多无谓的折腾和挫败感。

配置完成后，建议把~/.ssh下的私钥单独备份一份到加密存储里（密码管理器或者离线 U 盘），万一电脑丢失或系统重装，恢复密钥只需要分钟级别，不用重新走一遍平台端配置。