我在实际帮同事和同学排过无数次环境问题之后，越来越确信一件事：win10安装git不是难在“下载”和“双击”，而是难在安装向导里那一堆默认选项看不懂、选不对，后面才接连踩坑。比如装完发现CMD里敲不了git、一提交整个文件都被改换行符、远程仓库反复要密码、中文文件名显示成一串八进制数字。这篇文章我就按自己实操的流程，把Windows 10下安装Git的完整步骤从头到尾捋一遍，包括选择哪个安装包、安装向导每个选项怎么取舍、装完后的基础配置、SSH密钥怎么生成，以及我踩过和帮人排查过的高频问题。新手可以照着一路做下来，技术负责人也可以直接拿这套逻辑去写团队的装机规范。

1. 安装前的准备与下载渠道选择

1.1 先搞清楚你在Windows上装的到底是什么

Windows本身没有原生Git，大家平时在win10上双击安装的那个东西，正式名称叫“Git for Windows”，它把Git核心工具、Bash命令行环境、Git GUI、SSH客户端等打包成一个完整发行版。理解这一点很重要：你装完之后，系统里多了“git”命令，也多了一个叫“Git Bash”的终端程序。Git Bash不是简单的CMD美化版，它基于MSYS2环境，里面带着一套类Unix工具，所以你能在Git Bash里用ls、cat、grep这些命令，这套工具箱和Windows自带的同名命令不是一回事。

这也是为什么很多教程建议新手打开Git Bash操作，而不是CMD。CMD对Unix风格命令的支持很差，而Git很多操作习惯、提示信息都带着Unix的味道。在Git Bash里跑git status，输出可读性高，换行符也正常，整体体验比在CMD里舒服得多。你知道这一点，后面遇到问题时才不会被“为什么我这里没这个命令”绕晕。

1.2 下载渠道和版本选择，别去第三方站点

下载Git for Windows，直接去Git官方网站的Downloads页面就好。页面上一般会提供两个入口：64位安装包和32位安装包。现在绝大多数电脑都是64位系统，但老笔记本、部分嵌入式设备或者轻度办公平板还可能是32位。怎么判断？右键“此电脑”选“属性”，在系统信息里看“系统类型”。显示“基于x64的处理器”，选64位；显示“基于x86的处理器”或“32位操作系统”，选32位。拿不准的时候优先看系统类型，别根据CPU型号猜。

版本号方面，Git的迭代速度很快，正常选最新稳定版就好。下载时顺便看一眼文件大小，官方安装包通常几十到一百多MB，如果你下载的只有几MB甚至几百KB，大概率下成残缺文件。有条件的话，下载后校验一下SHA256；即使不想做校验，也至少认准官方网站的直达链接。我一直不建议从第三方下载站抓安装包，那些站点经常把Git官方包换壳打包，捆绑一堆用不上的推广软件，装完还不好清理。

1.3 安装版还是便携版，看使用场景决定

官网上除了标准安装包，还会提供“PortableGit”便携版。便携版不用安装，解压到某个目录后把它的cmd目录加入PATH就能用，甚至可以直接放在U盘里带走。它的优点是绿色、不写注册表、不留下右键菜单，适合公司电脑没有管理员权限的情况，也适合你在公用机器上临时用一下。缺点也很明显：右键菜单的“Git Bash Here”不会自动集成，凭证管理器用起来比较别扭，在多个终端里调用时要自己维护PATH。

我自己的建议是：长期开发用的电脑，老老实实装标准安装版，因为它会把右键菜单、文件关联、组件都配好，后续省心；只是临时演示、公司公用机器，才考虑用便携版。便携版被安全软件误报的概率会高一些，因为免安装程序没有数字签名信任链，遇到这种情况别慌，加信任即可，不要因为误报就去关闭系统防护。

2. 安装向导逐项拆解，看懂再点下一步

2.1 组件选择：哪些该勾，哪些可以保持默认

安装包运行后进入“Select Components”页面。默认勾选的项目基本覆盖了日常所需，我不建议为了“精简”取消太多。重点看这几个：

• 右键菜单集成：默认勾选“Git Bash Here”和“Git GUI Here”。这两个务必保留，在文件夹空白处一按右键就能打开Git Bash，比每次手动启动终端再cd过去高效太多。
• Git LFS：大文件存储组件。现在不少项目会放图片、音频、设计稿甚至模型文件，没装LFS的话仓库可能处于残缺状态。默认勾选，保留。
• 关联.git配置文件：可勾可不勾，双击划线配置文件时能用Git GUI打开，对多数人是锦上添花。
• 创建桌面快捷方式：属于个人喜好，无所谓。

在组件页下方有一个“Enable symbolic links”选项，默认不勾，新手千万不要手动勾上。Windows上的符号链接需要管理员权限，而且很多编辑器、构建工具对符号链接的处理并不好，开了之后反而容易碰到“Permission denied”一类的报错。这里保持默认就是最稳妥的。

2.2 默认编辑器：别让Vim卡住你的第一次提交

安装向导会让你选择Git使用的默认编辑器，默认值是Vim。Vim在程序员圈子里地位很高，但对新手极其不友好：你第一次执行git commit，如果没带-m参数，Git会打开一个编辑界面，没有基础的人会发现自己被困在里面，叫天天不应，连怎么退出都不知道。

所以我的建议是，在装Git之前，先跟着自己常用的代码编辑器选择。比如你已经装了VS Code，安装向导通常能自动识别并把它列出，这时直接选VS Code。这样以后执行git commit弹出的是VS Code的编辑窗口，写提交信息跟写普通文件没区别，保存关闭即可。如果电脑上暂时什么编辑器都没装，选Vim也不是不行，但你必须记住Vim的保存退出方式：先按i进入插入模式，输入提交信息，然后按Esc回到普通模式，再输入英文冒号加wq回车。就这几步，我远程帮人排查时反复念叨过很多遍。

2.3 PATH环境变量三选一，直接决定CMD能不能用git

安装向导里最关键的选项就是“Adjusting your PATH environment”。一共三个单选：

1. 仅在Git Bash中使用Git。选了它，CMD和PowerShell都不认识git命令，新人在VS Code集成终端里也敲不了git，必须手动打开Git Bash。
2. 从命令提示符和PowerShell中使用Git。这是推荐选项。它会自动把Git的可执行目录加入系统PATH，装完之后CMD、PowerShell、VS Code终端都能直接执行git。
3. 在PATH中加入Git和可选的Unix工具。这个不仅加了Git，还把一整套Unix命令搞进全局PATH，容易和Windows自带的find.exe等命令冲突，可能带来一些莫名其妙的问题，非特殊需求不建议选。

绝大多数人都应该选第二项。现代开发不是你永远只待在一个终端里，VS Code的集成终端、PowerShell脚本、某些自动化工具都会直接调用git，如果选了第一项，这些场景全部失灵，你还得回头重装。从命令提示符和PowerShell中使用Git，实际上是设置一个“为所有用户还是当前用户更改PATH”的补充选项，一般保持默认即可。装完之后如果发现CMD还是提示找不到命令，最常见原因是装完后没有重开终端——环境变量是在终端启动时读取的，旧窗口不会自动刷新。

2.4 换行符设置：CRLF和LF之争，在这里埋下大坑

安装向导进入“Line Ending Conversions”页面时，很多人会一头雾水。这里说的是Windows和Unix/Linux系统对文本文件行尾的不同处理：Windows默认用回车加换行，也就是CRLF；Linux和macOS一般只用换行，也就是LF。Git为了让大家跨平台协作时不至于每次打开文件都显示“整个文件被修改”，提供了自动转换机制。

三个选项分别是：

• “Checkout Windows-style, commit Unix-style line endings”：从仓库检出文件时转成CRLF，提交时统一转回LF。这是默认选项，适合Windows和Linux混合团队。
• “Checkout as-is, commit as-is”：完全不做转换，文件是什么样就什么样。适合所有成员统一用Linux/macOS，且仓库里已经明确约定LF的团队。
• “Checkout as-is, commit Unix-style”：检出时保持原样，提交时转成LF。使用场景相对少。

对于个人新手和大部分公司项目，直接保持默认第一项就好。除非你们团队已经有明确的.gitattributes规则，否则别觉得自己“懂”就去改“as-is”，很容易出现本地看着一切正常、git diff却大片变红的诡异局面。这个坑我在第4章会详细讲。

2.5 终端模拟器、Pull行为和凭据管理器

接下来会问“Which terminal emulator do you want to use?”。默认是MinTTY，这个终端比Windows自带的Console更好用，支持鼠标选择、字体渲染更顺滑、调整窗口大小也流畅。我建议保持MinTTY。如果是在老旧的办公电脑上，或者安全软件管控特别严格的环境里MinTTY启动缓慢，可以换成“Windows Console”，功能简单但兼容性更好。这个选项只影响“Git Bash”快捷方式启动后用什么终端显示，不影响你在CMD或Windows Terminal里调用git。

再到“git pull”的默认行为，默认是“Fast-forward or merge”，也就是git pull等价于先fetch再merge。另一个选项是rebase。在安装阶段，我永远不会让新人去改这个，保持默认就行。等你理解了merge和rebase的区别，再按团队约定去改也不迟。最后是“Choose a credential helper”，默认启用Git官方的凭证管理器。这个一定要保留，否则每次访问HTTPS远程仓库都会反复输账号密码，体验极其糟糕。

3. 装完之后的必做配置，别急着clone

3.1 验证安装，确认每一层都通了

装完Git后，不要直接去clone仓库，先花两分钟验证安装链路。打开开始菜单，找到Git Bash，执行git --version，看到类似git version 2.4x.x.windows.x的输出，说明核心工具没问题。然后右键桌面空白处，确认菜单里有“Open Git Bash here”，如果没有，说明右键集成组件没生效，可以重装或手动修复。

接着打开CMD，再执行一次git --version。如果CMD里也能正常输出，说明PATH配置成功；如果提示“不是内部或外部命令”，先关闭CMD再重新打开。大多数情况下，不是装错了，而是旧窗口没刷新环境变量。这一步验证到位，后面在VS Code终端、PowerShell里使用Git才能安心。

3.2 配置用户名和邮箱，commit记录的关键身份

Git每次提交都会带上作者信息，所以装完第一件事就是设置user.name和user.email。打开Git Bash，逐行执行：

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

注意，命令里的引号要用英文半角，不然会带着中文标点进去。--global的意思是当前Windows用户全局生效，这样这台机器上所有仓库默认都用这个身份。Git配置分system、global、local三个层级，优先级是local大于global大于system。如果你某个项目需要不同的提交身份，进入该项目目录后执行不带--global的git config user.name "另一个名字"，就只影响这一个仓库。

配置完可以执行git config --global --list检查所有全局配置。顺手也建议把默认分支名统一一下：

git config --global init.defaultBranch main

现在主流代码托管平台新建仓库时默认分支都叫main，本地初始化仓库时也统一成main，能少一些分支名的认知负担。

3.3 初始化一个Demo仓库，跑通add和commit

验证安装和配置最直接的方法，是在临时目录跑一次最基础的提交流程。

mkdir git-demo cd git-demo git init git status echo "hello git" > readme.txt git add . git commit -m "first commit" git log --oneline

这段命令做完，git status应该是干净的，git log能看到一条提交记录。这里用-m直接带提交信息，所以不会弹出编辑器；如果你想测试默认编辑器是否配置得当，可以执行一次不带-m的git commit，确认它能正常弹出并保存退出。跑通这个流程，说明Git的下载、安装、PATH配置、提交身份四个环节全部正常，可以放心开始实际项目。

3.4 SSH密钥生成与添加，让远程连接更省心

要用SSH方式连接代码托管平台，需要先生成密钥对。打开Git Bash执行：

ssh-keygen -t ed25519 -C "你的邮箱" -f ~/.ssh/id_ed25519

如果目标平台不支持ed25519算法，可以改用RSA：

ssh-keygen -t rsa -b 4096 -C "你的邮箱" -f ~/.ssh/id_rsa

回车后会提示输入passphrase，也就是口令。直接在本地开发机上使用的话，留空回车即可；如果在公用电脑上，强烈建议设置一个口令，否则私钥被别人拷走就能直接冒充你连接远程。生成完毕后，公钥内容是~/.ssh/id_ed25519.pub文件里的整段文本，执行cat ~/.ssh/id_ed25519.pub打印出来，复制到代码托管平台的“SSH公钥管理”页面保存。

测试连接用：

ssh -T git@你的平台地址

第一次连接会询问是否确认主机指纹，输入yes回车，看到欢迎信息说明密钥已经生效。这里有个Windows特有细节：.ssh目录默认在C:\Users\你的用户名\.ssh，如果你用管理员身份开了另一个终端，生成的.ssh目录可能落到C:\Users\Administrator下面，日常账号找不到，导致连接一直失败。个人开发建议在自己常用的标准账号下操作，不要图省事切管理员。

3.5 按需配置别名和颜色，提高日常操作体验

Git命令本身比较长，常用的status、log --oneline可以配成短别名，例如：

git config --global alias.st "status" git config --global alias.lg "log --oneline --graph --all --decorate" git config --global alias.cm "commit -m"

之后git st就等于git status，git lg能看到漂亮的提交历史图。再执行：

git config --global color.ui auto

这样git status和git diff的输出会有颜色区分，一眼就能看出增删改。还有一条git config --global push.default simple，新版本Git里已经是默认值，但写进配置也没什么坏处，可以避免旧客户端出现奇怪的推送行为。这些不是安装必需，但是属于“装完顺手配好，后面少折腾”的小习惯。

4. 日常使用中新手最容易踩的6个坑

4.1 CMD里找不到git命令，PATH没选对

症状非常典型：在CMD里输入git --version，提示“'git' 不是内部或外部命令”。排查看三点：第一，确认你已经重开终端；第二，检查环境变量里Path是否包含C:\Program Files\Git\cmd；第三，如果装的是便携版，注意git.exe其实在cmd目录而不是根目录，IDE里配置Git可执行文件时选错路径一样会失败。

如果Path确实没有，可以在“此电脑-属性-高级系统设置-环境变量”里，选中用户变量里的Path，点“编辑-新建”，粘贴C:\Program Files\Git\cmd，确定后重开终端。这里我特意强调改“用户变量”而不是“系统变量”，因为用户变量只影响当前账户，改错了也不至于搞乱整台机器。

4.2 整个文件在diff里变红，换行符策略不一致

Windows上最经典的问题之一：你在文件里明明没改任何内容，执行git diff却看到整份文件都被标记为修改。这通常是换行符策略不一致导致的。git diff逐行对比内容，如果本地文件是CRLF、仓库里是LF，或者某次保存时编辑器把行尾从CRLF换成了LF，Git就会认为每一行都变了。

处理思路是：先执行git config --global core.autocrlf，看当前值是多少，返回true是提交时转LF检出时转CRLF，返回input是不统一转换。然后看一看仓库里有没有.gitattributes文件。最可靠的团队做法是，在仓库根目录维护一份.gitattributes，明确不同后缀文件的换行规则，例如：

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

这比每台机器各自配置autocrlf靠谱得多。如果你只是个人项目积累了错误转换，可以先提交现有改动，然后执行git add --renormalize .再提交，Git会按当前规则重新标准化文件，去掉大量无意义的换行差异。

4.3 中文文件名显示成八进制，乱码的真相

在Windows的Git Bash里，如果你新建一个“测试.txt”，git status可能显示为"\350\257\225\350\257\225.txt"，看起来像文件损坏，其实这是因为Git默认对非ASCII文件名做转义，防止某些旧终端解析出错。解决很简单：

git config --global core.quotepath false

之后重新执行git status，中文文件名就会正常显示。如果Git Bash里提交信息、中文输出出现乱码，多数是终端编码设置问题，和Git本身无关。新版本Git for Windows默认使用UTF-8，旧版本可能需要在终端标题栏右键的选项里把编码调整为UTF-8。另外，如果文件内容本身是GBK编码，在Git Bash里自然会乱码，这不是Git的锅，是文件编码不一致，需要用编辑器把文件另存为UTF-8。

4.4 fatal: Not a git repository，层级路径混乱

在某个目录执行git status，报了fatal: Not a git repository (or any of the parent directories up to mount point /)，意思是当前目录不是仓库，往上层找也没找到.git目录。新手常见原因有三个：忘记了git init；以为自己在一个仓库里，实际站在仓库根目录的某个子文件夹；或者克隆项目时中断，.git目录没有完整生成。

排查时先执行pwd看当前路径，再执行ls -a看有没有.git目录。如果确实不在仓库里，要么用cd进入正确的仓库，要么在这里执行git init新建仓库。还有一种隐蔽情况：有人用符号链接把代码目录链到其他地方，Git检测工作树路径和实际路径不一致，也会报这个错。建议代码目录不要用符号链接绕来绕去，保持普通文件夹路径最省事。

4.5 push反复要密码或者认证失败，去看看凭据管理器

Windows下用HTTPS方式连接远程仓库时，第一次弹窗输入账号密码后，正常情况下之后都不再需要输入，因为有凭证管理器记住了凭据。如果出现每次push都弹窗，或者改了密码之后一直提示Authentication failed，多半是本地保存的旧凭据在捣乱。

在系统搜索框里输入“凭据管理器”，打开“Windows凭据”，找到以git:开头的条目，删除之后重新执行push，会再次弹出登录窗口，输入新密码就能刷新凭据。这个操作对Windows 10和Windows 11都适用。如果你更想彻底摆脱用户名密码的方式，提前配好SSH密钥，之后连接远程仓库完全不需要再输入账户密码，体验会比HTTPS方式清爽很多。

4.6 安全软件拦截和权限陷阱

Git Bash里有一些和普通Windows程序不太一样的可执行文件，比如unzip、bin目录下的各种工具，偶尔会被Windows自带的Defender或第三方安全软件标记风险。遇到这种情况，先确认安装包来自官网，再看具体被拦的是哪个文件，然后把这个文件或Git安装目录加入安全软件的排除项。不要为了“能用”就去关闭系统防护，Git是全世界最流行的开发工具之一，被误报通常是安装包被第三方动过手脚，或者软件规则太旧导致。

另一个权限坑是安装时用了管理员账号，但平时用普通用户操作仓库，遇到某些hook脚本或全局配置文件写入失败，报Permission denied。规范做法是：仓库目录放在用户目录或非系统盘的普通文件夹中，日常开发不要主动用管理员身份跑终端，绝大多数权限类问题都会消失。

5. 卸载、升级与迁移的实操经验

5.1 卸载Git，别留一堆残渣

如果不再需要Git，在Windows“设置-应用-已安装的应用”里找到Git并卸载即可。卸载程序会清掉主文件和大部分注册表项，卸载后建议打开环境变量，手动清除Path里残留的C:\Program Files\Git\cmd，否则终端里可能还留着一个“找不到的命令”的僵尸路径。右键菜单如果还有“Git Bash Here”的残留，一般重启一次文件管理器就能刷新。特别提示：全局配置.gitconfig不会随着卸载消失，它独立于安装目录存放在用户目录下。如果后续不想让新装的Git继承旧配置，手动删除C:\Users\你的用户名\.gitconfig这个文件就好。

5.2 升级之前，先备份.ssh和.gitconfig

Git没有内置自动更新，升级新版本通常还是去官网下载安装包，再覆盖安装到原目录。覆盖安装一般不会动你已经生成的SSH密钥和全局配置，但我在给同事做升级时，习惯先把两方面内容备份一份：

• 用户目录下的.ssh整个文件夹，里面包含私钥、公钥和可能的config文件。
• 用户目录下的.gitconfig全局配置文件。

把这两样复制到备份目录，升级完成后万一发现连接远程异常、提交身份丢失，可以快速恢复。升级后如果执行git lfs version提示命令不存在，大概率是安装时没勾选LFS组件，重新运行安装程序补装即可。

5.3 换新电脑，五分钟迁移Git环境

新电脑上装Git后，不需要把所有配置重新敲一遍。直接把旧电脑上的.gitconfig文件复制到新机器的用户目录，把.ssh文件夹也复制过去。如果之前为多个平台生成过不同的密钥文件，记得连config文件一起拷，这样不同平台会按config里的规则自动选择对应的密钥，不用每次手动指定。复制完成后，先执行一条ssh -T命令确认连接，再clone一个仓库试一下，基本就能正常开工。

这里我在实操中的体会是，很多人换电脑后习惯凭记忆重新配置环境，结果漏了这个那个，不如复制文件来得完整高效。你们完全可以把.gitconfig和.ssh放进自己的备份目录，形成固定的“装机三件套”，以后不管是换电脑还是重装系统，恢复开发环境都能控制在十几分钟内。最后再分享一个小技巧，装完新版本Git后在Git Bash里执行一次git update-git-for-windows，会弹出一个升级检测窗口，后续版本更新时用它检查当前是否为最新，比时不时去官网翻页面靠谱。