Windows 下 Git 完整配置教程：从安装到 SSH 密钥与推送

很多刚接触编程的朋友，第一次在 Windows 上装 Git 就被一堆术语劝退了：什么 Bash、什么 SSH、什么换行符，看着就头大。远程仓库连不上、push 一直要密码、命令行中文乱码，这些坑我早年做开发时基本全踩过一遍。这篇教程不整虚的，全程用 Windows 11 演示（Win10 也完全通用），从 Git 下载安装讲到环境变量配置，再一步步把 SSH 密钥生成好、配到 GitHub 和 Gitee 上，最后带你完成一次完整的提交推送。目标只有一个：照着做，谁都能配好一套能直接干活的环境。

这个教程适合哪些人？刚入门的大学生、从其他版本管理工具转过来的同事，或者本地写代码想备份一份到云端仓库的朋友。不管你之前有没有命令行基础，只要按步骤来就行。我会把我实际踩过的坑、当时没想明白的点，都明确标注出来。

1. 动手之前先搞懂：Git 到底是什么，我们为什么要折腾它

1.1 版本控制的核心价值

Git 是一个分布式版本控制系统，这句话听起来很绕，说人话就是：它能帮你记录项目文件每一次改动的“快照”，并且允许你在任意时间点回退、对比、合并代码。你可以把它理解成一个拥有“后悔药”和“多分支平行宇宙”能力的文件管家。

很多人刚学的时候会混淆 Git 和 GitHub。Git 是本地运行的版本管理工具，GitHub/Gitee 是托管代码的远程平台。你的提交记录、分支切换、历史回滚这些操作全部在本地完成，只有在你显式执行 push 时才会把本地提交推送到远程。这也是 Git 和早期集中式版本控制（如 SVN）最大的区别：本地就是一个完整仓库，断网也能随手提交，等有网了再同步。

从 2005 年 Linus 发布第一个版本到现在，Git 已经成了事实上的行业标准。无论是个人开源项目还是公司大型工程，几乎所有代码托管平台（GitHub、GitLab、Gitee、Bitbucket）都基于 Git 工作流。所以掌握 Git 不只是学会一个工具，更是打通与整个开发世界协作的基础。

1.2 这一套流程到底怎么运转

我们在这篇教程里要做的事，可以拆成三点：把 Git 程序装进 Windows；告诉 Git 你是谁（全局环境配置）；生成一把 SSH 密钥，让本地和远程仓库之间建立信任关系，不用每次输入账号密码。

SSH 密钥这里多说一句，很多新手卡在这。它的原理是本地生成一对密钥：一把私钥（id_ed25519）和一把公钥（id_ed25519.pub）。私钥自己保存，公钥添加到远程仓库平台。通信时，远程平台用公钥验证你的身份是否匹配本地私钥，验证通过就放行。整个过程不需要输入密码，相当于给你的电脑发了一张“门禁卡”。

为什么不用 HTTPS 呢？HTTPS 也能用，但每次 push 都要输用户名和密码（或者 Personal Access Token），虽然可以凭据管理器记住，但多平台、多账号情况下很容易弄混。SSH 一旦配置好，后续 clone、push 都是无障碍直连。对于长期开发和频繁提交的场景，SSH 是更省心的选择。

2. Windows 下载与安装：全流程细节拆解

2.1 去哪里下载，版本怎么选

下载 Git 只有一个官方渠道，就是 Git 官网（git-scm.com），进入后页面顶部会看到 "Download for Windows" 按钮，点击后自动跳转到下载页面。官网会根据你的系统位数（64 位或 32 位）提供对应安装包，2026 年看基本所有机器都是 64 位了，32 位安装包已经很少更新，除非你是老旧设备否则不用考虑。

还有一个细节：选版本。官网一般提供两个下载入口，一个是当前最新版（如 2.4x.x），另一个是维护版本。对新手来说直接用最新版即可，Git 版本迭代基本是向下兼容的，不用担心升级后命令不认。

提示：你可能会在网上搜到很多第三方站点的所谓“Git 汉化版”“Git 去广告版”，不建议下载。官网原版支持多语言，安装时你可以选简体中文界面，完全没有必要用任何修改过的渠道安装包。第三方渠道无法保证软件完整性，安全性隐患很大。

2.2 安装向导中点开的关键选项

下载完成后双击安装包，会进入安装向导。Windows 版本默认使用 Inno Setup 打包，整个向导全程可点"Next"，但有几个关键页面需要手动调整，我逐个说。

Select Components（选择组件）：默认勾选了 Git Bash Here、Git GUI Here、Add a Git Bash Profile to Windows Terminal。这些全部保留。尤其 Git Bash Here 很重要，它会在你鼠标右键菜单里增加"Open Git Bash Here"选项，方便随时在项目目录打开命令行。

Default editor（默认编辑器）：默认是 Vim。如果你熟悉 Vim 没问题，不熟悉的话强烈建议选 Visual Studio Code 或 Notepad++。因为当你执行 git commit 且没有加 -m 参数时，会打开编辑器让你写提交信息，Vim 对于新手来说容易卡在"怎么保存退出"这个问题上。我见过太多同事在 Vim 里输入 commit 消息后不知道怎么退出，最后强制关掉终端导致提交失败。如果你当前没装 VS Code，先选 Vim，后面随时能用命令改。

Adjusting your PATH environment（PATH 环境变量调整）：默认选项是 "Git from the command line and also from 3rd-party software"。这个必须保留默认，它会把 Git 的可执行文件路径自动加入 Windows 系统 PATH 环境变量，这样你在 CMD、PowerShell 里都能直接敲 git 命令。

Choosing HTTPS transport backend：默认是 OpenSSL，保留默认。

Line ending conversions（换行符转换）：这个页面有 3 个选项，被问得最多。默认选项是第一个 "Checkout Windows-style, commit Unix-style line endings"，意思是不管仓库里实际存的是 LF（Unix 换行符）还是 CRLF（Windows 换行符），检出到本地工作区时统一转成 Windows 的 CRLF，提交时再转回 LF 存入仓库。对于只在 Windows 上开发的个人项目，这个选项最省心，保留默认即可。

如果你的团队是多人跨平台协作（有人用 macOS/Linux，有人用 Windows），或者你在做开源项目，建议改成第二个选项 "Checkout as-is, commit Unix-style line endings"，让本地文件保持原样，提交时统一转 LF。避免那种"我明明只改了一行代码，git diff 却显示整个文件都变了"的换行符灾难。

Use a terminal emulator（使用哪个终端模拟器）：默认是 "Use MinTTY"。MinTTY 比 Windows 默认控制台窗口的功能更强，支持窗口缩放、粘贴快捷键更顺手。我之前试过 Windows 默认的 console host，配合 Git Bash 会偶尔出现中文渲染问题，所以这里也直接用默认的 MinTTY。

连续 Next 后点击 Install，等待安装完成。整个过程大概一两分钟，全程不需要额外重启。

2.3 装完如何验证安装结果

安装完成后，按 Win 键输入"Git Bash"，打开终端（或者在任何文件夹右键选 Git Bash Here），输入：

git --version

如果返回类似git version 2.48.1.windows.1这样一行，说明 Git 已经装好了。再顺手验证一下 PATH 是否生效，在 CMD 或 PowerShell 里输入同样的命令，如果不报"不是内部或外部命令"就是正常。

还有一种情况：你装的 Git 版本比较新，第一次打开 Git Bash 会提示图标索引服务之类的通知，直接忽略即可，不影响使用。

3. 环境配置：不配好这些，后面处处是坑

3.1 全局用户名和邮箱

装好 Git 后第一件必做的事，是告诉 Git 你是谁。这里配置的是全局身份信息，它会被写入到每次 commit 记录里，远程仓库的提交历史会显示这个用户名和对应邮箱。

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

我实际操作中的建议：user.name 尽量用拼音或者英文，避免某些代码托管平台对中文显示支持不完善。邮箱务必用你注册 GitHub/Gitee 的邮箱，否则提交记录不会关联到你的账号，贡献绿格子和提交人信息都会对不上。

检查配置是否写入成功：

git config --global --list

会输出你刚设置的信息。注意，Windows 下这个文件存储在用户主目录的.gitconfig文件（比如C:\Users\你的用户名\.gitconfig），用记事本能直接看。

注意：--global参数的意思是全局生效，影响这台电脑上所有仓库。如果你的电脑既有个人项目又有公司项目，公司项目通常需要单独在仓库内设置不同的用户名邮箱，可以在项目目录下去掉--global重新设置一次，该仓库的配置会覆盖全局配置。

3.2 换行符（CRLF/LF）的经典配置

前面安装时选过换行符处理方式，这一节教你如何在安装后通过命令调整。多设备开发、跨平台协作的朋友经常会遇到 git 提示warning: LF will be replaced by CRLF，这不是错误，但容易让人困惑。

Windows 上如果你希望 Git 在检出时自动把 LF 转成 CRLF（Windows 原生换行符），提交时转回 LF，执行：

git config --global core.autocrlf true

如果你是 macOS/Linux 用户（或者 Windows 上写 shell 脚本、配置文件需要保持 LF 的场景），把它设成 input 更合适：

git config --global core.autocrlf input

这个配置的核心思路是：仓库内部统一使用 LF，避免跨平台 diff 混乱；工作区按当前系统的换行习惯呈现。除非你能百分百确定项目里所有文件都是 LF 且不会和其他平台同事协作，否则不建议设成 false。

3.3 解决 Git Bash 中文乱码问题

Windows 上用 Git Bash 处理中文文件名、中文提交信息时，乱码是几乎每个人都会遇到的坑。表现是git status里中文文件名显示成一串转义符（类似\345\233\276\347\211\207），或者 commit message 里的中文变问号。

第一类问题的根源是 Git 默认对非 ASCII 文件名进行了转义显示。执行：

git config --global core.quotepath false

设置后，中文文件名会正常显示，不会变成八进制转义码。

第二类乱码，需要调整 Git Bash 终端的编码。在 Git Bash 窗口标题栏右键，选择 Options（选项），在 Text（文本）选项卡里找到 Character set（字符集），把默认的 UTF-8 保持住，同时把 Locale（区域设置）调整为zh_CN或C，一般能解决大部分中文显示问题。如果你在用 Windows Terminal 做宿主，需要把 profile 的编码设为 UTF-8，命令是：

git config --global gui.encoding utf-8 git config --global i18n.commit.encoding utf-8 git config --global i18n.logoutputencoding utf-8

这三条命令分别保证 GUI 界面、提交信息、日志输出按 UTF-8 处理，对于纯粹中文环境的 Windows 用户来说，配置了就省心很多。

3.4 通过环境变量验证安装路径

早年间装 Git 还要手动改系统 PATH，现在的安装包已经自动化处理了，但偶尔会遇到装完 CMD 里敲 git 还是没反应的情况。原因多半是 PATH 环境变量设置异常。

检查方法：Win 键搜索"编辑系统环境变量"，打开"环境变量"窗口，在"系统变量"里找 Path，双击编辑，确认里面有这样一条：C:\Program Files\Git\cmd（路径取决于你安装时选的目录）。如果没有，点击"新建"手动添加，然后点确定保存。设置完必须重新打开终端才生效，这也是很多人改完环境变量发现不起作用的常见原因——终端没重启。

4. SSH 密钥：一次性配置，从此告别密码

4.1 密钥生成前的准备工作

在生成 SSH 密钥之前，先确认你本地已有密钥，避免重复生成覆盖掉旧配置。打开 Git Bash，执行：

ls -al ~/.ssh

如果显示No such file or directory或者目录为空，说明还没生成过密钥，可以放心走下一步。如果存在id_ed25519或id_rsa这类文件，说明之前生成过，也有可能是系统预置的。你可以直接复用旧密钥（把对应公钥加到托管平台即可），也可以为了安全重新生成，这个看个人习惯。

另外，如果你在一台电脑上同时使用 GitHub、Gitee、GitLab 等多个平台，最省事的方式是：为每个平台生成独立密钥，然后通过配置文件做多账号切换。这个内容我会在后面单独拆一个小节。

4.2 生成 SSH 密钥的具体步骤

在 Git Bash 中输入：

ssh-keygen -t ed25519 -C "your_email@example.com"

这里的-t ed25519表示使用 Ed25519 算法生成密钥。相比传统的 RSA 2048 位，Ed25519 密钥更短、生成更快、安全性更高，是目前 GitHub、Gitee 都推荐的首选算法。如果你的环境比较老，可以用-t rsa -b 4096生成 RSA 密钥，也是常用方案。

-C后面跟的是备注信息，一般写你的邮箱就行，主要是方便区分哪台机器、哪个账号的密钥。

输入命令回车后，会出现这样的提示：

Generating public/private ed25519 key pair. Enter file in which to save the key (/c/Users/你的用户名/.ssh/id_ed25519):

直接回车确认默认路径。接着提示：

Enter passphrase (empty for no passphrase):

passphrase 是私钥的额外保护密码，推荐设置一个（比如你的某个复杂密码组合）。设置后每次使用私钥需要输入一次，虽然多了个步骤，但如果电脑丢失，没有 passphrase 的人拿到私钥文件也无法使用。如果你图省事，直接回车设空也不是不行，安全性上弱一点。这一步我个人的建议是：办公电脑设 passphrase，个人电脑看你对私钥丢失风险的接受程度。

完成后，~/.ssh目录下会多出两个文件：id_ed25519（私钥）和id_ed25519.pub（公钥）。公钥就是你要添加到远程平台的内容，私钥永远不要发给任何人。

4.3 公钥加到 GitHub 和 Gitee 的操作步骤

先查看公钥内容：

cat ~/.ssh/id_ed25519.pub

输出的一长串字符就是公钥，格式一般是ssh-ed25519 一大串字符 your_email@example.com。把整行内容复制下来。

GitHub 添加公钥：登录 GitHub，点击右上角头像，进入 Settings，左侧菜单选 "SSH and GPG keys"，点右上角绿色按钮 "New SSH key"。Title 随便填一个能识别的名字（比如 "My Windows PC"），Key type 保持默认，把公钥粘贴到 Key 输入框，点 "Add SSH key" 完成。

Gitee 添加公钥：登录 Gitee，点头像进入设置，左侧找 "SSH 公钥"，把公钥粘贴进去，Title 填备注，确认添加。

GitLab 的路径也类似，通常是在 Preferences 或 User Settings 里。添加公钥不会触发手机验证，但某些平台首次添加会让你输入一次登录密码确认身份。

4.4 验证 SSH 连接是否成功

配置完成后，在 Git Bash 里验证连接状态：

ssh -T git@github.com

如果返回：

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

说明 GitHub 连接成功。Gitee 对应验证：

ssh -T git@gitee.com

返回Hi 你的用户名! You've successfully authenticated, but Gitee does not provide shell access.即代表成功。

首次执行时会出现一个确认指纹的提示，输入yes回车，这个确认操作会把远程主机写入 known_hosts 文件，后续再连接就不会询问了。如果你不确定指纹是否可信，可以先去官方文档核对；大多数情况直接 yes 即可。

4.5 多平台多账号如何配置，避免密钥冲突

一个很典型的需求：我同时用 GitHub 和公司内部的 GitLab，而且公司账号和个人账号的邮箱不一样。如果生成密钥时都使用默认文件名id_ed25519，后生成的会覆盖前面那个，或者两个平台的认证会互相干扰。

解决方案是在~/.ssh目录下创建config文件，用文本编辑器新建一个没有任何后缀的文件（注意文件名就叫 config），写入：

# GitHub Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github # Gitee Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee

对应的密钥文件名要和你生成时指定的一致。生成方式是在 ssh-keygen 时输入不一样的文件名：

ssh-keygen -t ed25519 -C "github@example.com" -f ~/.ssh/id_ed25519_github ssh-keygen -t ed25519 -C "gitee@example.com" -f ~/.ssh/id_ed25519_gitee

把两把公钥分别加到对应平台，再验证两个 Host 是否都能通。这样本地就实现了多平台独立认证，互不干扰。这是我在公司电脑上实际在用的方案，实测下来很稳。

5. 第一次实战：用 SSH 完成克隆、提交与推送

5.1 在托管平台创建远程仓库

以 Gitee 为例，登录后点击右上角"新建仓库"，仓库名称随便起（比如my-first-repo），选择公开还是私有。这一步不用细调太多选项，Git 仓库是后面通过命令初始化的，页面上的"初始化仓库"勾选框看你自己，勾了会帮你生成 README 和 .gitignore，不勾也能用。

创建完成后页面上会出现仓库地址，记得选择 SSH 格式，形如git@gitee.com:你的用户名/my-first-repo.git，不要把 HTTPS 地址复制错了。

5.2 克隆远程仓库到本地

在 Git Bash 里切换到你希望存放项目的目录：

cd /c/Users/你的用户名/projects

如果目录不存在，先创建：

mkdir -p /c/Users/你的用户名/projects

然后执行：

git clone git@gitee.com:你的用户名/my-first-repo.git

克隆成功后当前目录下会出现my-first-repo文件夹，里面会自动带上远程仓库已存在的所有文件和 Git 历史记录。如果你创建仓库时没有勾选任何初始化选项，克隆下来就是一个空仓库，本地文件夹里只有一个.git隐藏目录。

5.3 本地文件提交和推送的完整流程

现在往仓库里放一个文件，比如新建hello.txt，内容写一行"Hello Git"。在 Git Bash 中进入仓库目录，按顺序执行：

git status

这一步查看当前状态，你会看到hello.txt在 Untracked files 区域，意思是 Git 还没跟踪它。

git add hello.txt

把这个文件加入暂存区。如果你希望一次添加所有改动过的文件，用git add .，但建议新手尽量明确添加目标，避免把不该提交的文件（比如本地配置、密钥、编译产物）带进去。

git commit -m "feat: add hello.txt"

提交到本地仓库，-m后面是提交信息。提交信息尽量写清楚这次改了什么，比如feat: 新增 hello.txt 文件或者英文描述。Git 社区有约定俗成的提交信息格式（type: 描述），例如feat、fix、docs、refactor，建议从一开始就养成好习惯。

git push

把本地提交推送到远程。因为我们已经配置好 SSH，这里不会要求输入账号密码。输出末尾如果显示类似master -> master或main -> main的内容，说明推送成功。

顺带提一下分支名：新版本 Git 初始化仓库默认分支名是main（老版本是master）。用git branch可以查看当前分支名。推送完整一点可以写成：

git push -u origin main

首次推送加-u会把本地分支和远程分支建立关联，后续直接git push就行。

5.4 从远程拉取更新的正确姿势

每次开始干活的习惯是先把远程最新代码拉下来：

git pull

这个命令等价于git fetch+git merge，会把远程新提交合并到本地当前分支。如果本地工作区和远程存在冲突，Git 会提示冲突文件，需要手动解决再提交。新手阶段如果不在多人协作项目里，很少遇到冲突，但养成先 pull 再开工的习惯没有坏处。

6. 常见问题速查：我把踩过的坑都写在这里

6.1 问题速查表

我在培训新人和自己排查过程中，总结了一份 Git 在 Windows 上的高频问题表，可以直接对照处理。

6.2 密钥相关的两个高频坑

坑一：公钥没错还提示 Permission denied。排查思路按顺序走：先确认 ssh-agent 是否在运行，并检查它是否加载了你的私钥。Git Bash 中执行：

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

如果之前生成密钥时指定了自定义文件名，比如id_ed25519_github，记得改为对应路径。有时候 Git Bash 重启后服务没自动启动，手动加载一次就能解决。想一劳永逸的可以把这两行加到~/.bashrc里。

坑二：SSH 密钥添加好了但 clone 时选错了地址。复制地址时请严格使用平台提供的 SSH 克隆地址。Gitee 的 SSH 地址是git@gitee.com:xxx，GitHub 是git@github.com:xxx，注意用户名部分永远是git，不是你的登录用户名，这也是新手最容易写错的地方。

6.3 仓库误操作后的恢复思路

git reset是新手容易搞出问题的地方。如果你把暂存区的文件搞乱了，可以用：

git reset HEAD 文件名

把文件从暂存区撤回，但工作区的修改还在。如果文件已经 commit 了，想撤销某个提交但保留改动：

git reset --soft HEAD~1

--soft只撤提交、保留改动，--hard会连同工作区改动一起丢弃，这是危险操作。除非你确定不要了，否则我不建议用--hard。如果你用--hard删掉的东西还没 push 到远程，用git reflog还能找到之前的提交哈希，然后git reset --hard 哈希值救回来。reflog 是我能想到最可靠的后悔药。

6.4 Windows 防火墙对 Git 的影响

偶尔会遇到 Git 操作超时或者连接被拒，排除密钥、地址问题后，可以检查 Windows Defender 防火墙是否拦截了 Git 自带的 ssh 进程。遇到这种情况，在"允许应用通过防火墙"里找到 Git 相关项，确保专用网络和公用网络都勾选允许。这个问题不算高频，但排查起来容易忽略。

最后聊几句大实话

教程写完，我再说点纯个人体会。Git 的配置环节讲究"一次配好，长期省心"，但早期你可能会反复改配置来回折腾，这很正常，不用怕。如果你刚配完 SSH 密钥就用不了，别急着怀疑人生，九成问题出在公钥复制多了换行、或者远程地址复制成了 HTTPS。把这两个点检查一遍，再跑一次ssh -T git@github.com看提示，基本都能定位。

另外，我建议你装完 Git 后再做一件事：去把 VS Code 装上，然后在终端里把默认 shell 换成 Git Bash，直接在编辑器里写代码、敲命令、看 diff，整个体验会比单独开命令行舒适很多。开发环境的舒适度直接影响你写代码的频率，这不是闲话，是我这些年观察团队新人后最深的感受。

这整套流程你跟着操作一遍大概二十分钟，配置完成之后，后续 clone、push、pull 都是秒级连接的无障碍体验，这才是开始 Git 工作流的正确姿势。