每次帮新同事配开发环境我都会发现一个规律越是觉得“装软件这种小事不用教”的人越容易在Git安装上翻车。2026年了Git的Windows安装向导表面上还是“一路Next”的风格但中间藏着好几个会影响你未来一两年开发体验的选项——PATH怎么选、换行符怎么处理、默认编辑器用什么、HTTPS后端走哪套协议。选错了当时没感觉等你用IDE提交代码时看见满屏diff、或者终端里冒出一堆莫名其妙的fatal报错才会意识到问题早在安装那一步就埋下了。所以这篇我决定把安装过程拆成“能对上号”的图文级详解从下载渠道和版本选择开始到安装向导每一屏的真实含义再到装完后的初始化配置、SSH密钥生成、第一次完整提交闭环最后聊透几个高频报错。不管你是刚转行准备系统学Git的新人还是要帮团队做环境标准化、被同事反复问“为什么我clone不了”的救火队员这篇都能直接照着操作。1. 为什么2026年了Git安装依然值得单独写一篇1.1 我看到的安装误区一路Next的代价先讲一个几乎每年都会遇到的例子。之前帮一个做前端的朋友排查问题他打开终端敲git status屏幕提示fatal: not a git repository。他以为是Git坏了卸载重装了三遍还是老样子。后来我看了一眼他的工作目录里面根本没有.git文件夹——他站在一个普通文件夹里执行Git命令那当然会报这个错。这个例子说明一个问题很多人看安装教程只看了前半段“双击安装包、下一步、完成”却没理解安装完之后Git的运行逻辑。安装Git确实不难两分钟就能装完但安装不等于可用更不等于好用。难的是理解安装向导里那些英文选项到底在决定什么以及装完之后如何让Git和你的IDE、你的代码托管平台、你的团队协作方式真正配合起来。我一直跟团队里的人说安装Git这件事30%是下载和点击70%是配置和验证。这篇教程会把那70%的坑提前替你踩平。1.2 安装向导早已不是“双击下一步”那么简单Git for Windows的安装向导整体框架保持了多年稳定但选项一直在增加。早期版本纠结的是“要不要装Git GUI”后来加入了换行符转换、终端模拟器选择再后来又增加了Git LFS、HTTPS后端、符号链接支持、实验性文件系统监视器等选项。到2026年安装器本身已经不只是“装一个命令行工具”而是“为你的开发环境做一次系统级配置”。这些选项背后代表的是不同的使用习惯和协作协议。举个最典型的例子换行符转换。Windows下文件默认是CRLF结尾Linux和macOS是LF结尾。同一份代码在不同系统之间来回传递如果转换策略设置不当git diff会把整个文件都标记为修改那种“我明明只改了一行为什么diff显示几百行变化”的经典问题根子就在安装时那个不起眼的line ending选项上。所以别再觉得安装教程没有技术含量这一套东西真正吃透的人排查问题的速度会快很多。1.3 这篇教程覆盖的范围与阅读建议这篇教程以Windows为主线因为绝大多数刚接触Git的读者都在Windows环境里工作。macOS用户我会在下载环节单独说两句Linux用户一般用包管理器三行命令的事。全文按真实操作顺序推进先讲怎么选版本、怎么下载、怎么校验文件完整性再逐屏拆解安装向导的每个选项告诉你选什么、为什么装完之后进入初始化配置阶段重点讲user.name、user.email和配置优先级然后走一遍“生成SSH密钥、配置到Gitee、clone仓库、首次提交”的完整闭环最后是高频故障排查。我的建议是如果你是完全没装过Git的小白从头到尾按顺序走如果你已经装好但平时用起来总有些别扭可以直接跳到第三章和第四章大概率能找到答案如果你是团队里负责带新人的那个人建议重点看第三、四章把环境标准化的逻辑讲给新人听。2. 下载环节官网渠道、版本判断与文件校验2.1 官网下载与版本命名规则Git的官方网站是git-scm.com这是唯一权威下载渠道。我见过不少朋友在搜索引擎里搜“Git下载”点进了第三方下载站结果装了一堆捆绑软件还下载到旧版本。2026年的Git稳定版已经走到2.5x时代版本号格式是2.x.x从2.47开始已经支持了很多新特性。判断版本新旧很简单年份越近小版本号越大功能越完整。进入官网后页面会自动根据操作系统显示对应的下载按钮。Windows用户会看到两种选择64-bit Git for Windows Setup和32-bit Git for Windows Setup。除非你的电脑还是十几年前的老古董否则一律选64位。还有一个Portable版本这是便携版不需要安装解压就能用适合放在U盘里临时用但不适合作为日常开发环境因为它的上下文菜单集成和环境变量配置都受限制。macOS用户可以直接下载macOS安装包也可以通过Homebrew安装brew install git。Linux用户更简单Debian系用apt install gitRed Hat系用yum install git而且仓库里的版本往往已经很新。这里我多说一句Linux系统包里带的Git版本一般够用不需要为了追新版本去手动编译源码浪费那个时间没必要。2.2 官网下载慢的应对方案Git官网服务器在海外部分地区的网络环境下下载速度确实不理想。如果你遇到这个问题优先选择国内高校或云厂商的镜像站。常用的镜像有清华开源软件镜像站、阿里云开发者社区镜像站、腾讯软件源等在镜像站里搜索git-for-windows会看到和官网对应的安装包文件列表。用镜像下载时要注意两个细节第一认准Git-x.x.x-64-bit.exe这类完整安装包文件不同镜像站的目录命名略有差别但exe文件不会搞错第二下载完成后看一眼文件大小Git for Windows完整安装包一般在60MB到70MB之间。如果下载下来的文件只有几十KB或者几MB那肯定是下载到了错误的文件比如某些镜像站会额外提供不带自带Git LFS的精简版本。我在实际工作中发现很多同事下载失败其实不是网络问题而是从镜像站下载了一个MinGit精简包——那个只包含命令行工具没有Git Bash、没有右键集成装完之后体验残缺。所以下载前一定看清文件名。2.3 用SHA-256数字指纹验证安装包完整性这一步很多人会跳过但我觉得值得花十秒钟做一下。官网每个版本都会提供SHA-256哈希值下载完成后可以手动计算文件的哈希值进行比对。Windows 10/11自带certutil命令certutil -hashfile C:\Users\你的用户名\Downloads\Git-x.x.x-64-bit.exe SHA256把输出的64位十六进制字符串和官网上标注的哈希值对比一致就说明文件没有损坏、没有被植入任何东西。我之所以强调这一步是因为Git安装包会被杀毒软件和安全工具重点关注偶尔会出现下载过程中被杀软拦截导致文件不完整的情况。哈希校验能一次性排除掉“文件损坏”和“下载不完整”这两类问题后面安装时少折腾很多。3. Windows安装向导逐屏拆解每个选项背后的真实影响3.1 组件勾选哪些必须选哪些可以忽略双击安装包后第一屏是GPL许可证说明直接Next。第二屏是安装目录选择默认是C:\Program Files\Git。我给所有团队成员的建议都是保持默认不要把Git装到D盘自定义路径。原因很简单Git体积只有两三百MB不存在“占用C盘空间”的担忧一旦改了路径后续IDEA、VS Code、GitHub Desktop等工具自动检测Git时可能找不到还得手动去指定路径徒增麻烦。真正需要认真看的是Select Components这一屏。界面里会有几个勾选项我逐个说Additional icons是否创建桌面图标。无所谓后面基本不会从桌面图标启动Git不勾也不影响任何功能。Windows Explorer integration这个建议勾选。它会在右键菜单里加入Git GUI Here和Git Bash Here两个入口。这两个右键入口是Windows下使用Git最舒服的方式没有之一。你想在哪个目录执行Git命令右键就能打开一个已经定位到该目录的终端。Associate .git configuration files with default editor把.gitconfig等配置文件和默认编辑器关联。建议勾上否则以后打开Git配置文件时会被系统用记事本之类不明不白的程序接管。Associate .sh files with default editor把.sh脚本关联到默认编辑器。这个也建议勾上Windows上处理脚本文件时会方便一些。Git LFSLarge File Storage如果你要管理超过100MB的大文件或者仓库里涉及设计稿、二进制资源建议勾选。不勾也不影响常规代码仓库后面需要时随时可以用git lfs install补齐。Scalar这是微软参与的一个性能优化工具对大型仓库有加速效果。如果你平时只是做一些小型项目可以不装如果在一个巨大的monorepo里工作装上没坏处。3.2 PATH环境变量与默认编辑器直接影响日常操作习惯的两个选项Select Components之后是Select Start Menu Folder默认就行。接着进入我认为整个安装过程中最关键的两屏。第一屏是Choosing the default editor used by Git。默认选项是Vim新手的“劝退重灾区”——因为执行git commit需要填写提交说明时会打开Vim而很多人不知道如何在Vim里输入并退出卡在终端里不知所措。这里我建议直接选Use Visual Studio Code as Gits default editor。如果你平时不用VS Code选Notepad或者nano也行唯独不要选Vim。选错的话Git照常能用但每次提交都要和Vim搏斗体验非常糟糕。第二屏是Adjusting your PATH environment三个单选项Only use Git from Git Bash最保守的选项Git命令只在Git Bash里可用IDEA、VS Code这些工具很可能找不到git命令。只推荐对系统安全有极端要求的环境。Recommended把Git核心目录加入系统PATH命令在Git Bash、命令提示符、PowerShell以及各种IDE里都能直接使用。这是官方推荐也是绝大多数人的正确选择。Use Git and optional Unix tools from Command Prompt不仅加PATH还会把一批Unix命令ls、find、grep等注入系统目录。看起来很方便但这些命令和Windows自带命令存在命名冲突风险比如Windows系统目录里也有find.exe装了之后谁生效完全取决于PATH顺序容易制造莫名奇妙的兼容问题。我的建议非常明确选第二项Recommended不要为了省一两个Linux命令去冒冲突的险。3.3 换行符转换新手最容易埋雷、老手也常翻车的选项接下来是Configuring the line ending conversions三个单选选项我把它称为“整个安装向导里最需要理解的一屏”。先说背景Windows系统里文本文件默认用回车换行CRLF\r\n结尾而Linux和macOS系统用换行LF\n结尾。Git仓库里存储的行尾符格式是LF。当你把仓库克隆到Windows时Git需要决定工作区文件用什么行尾符当你提交时又需要决定把工作区的行尾符转回LF再入库。这个转换过程选错策略就会出现“我只改了一行但diff显示整个文件都变了”的灵异事件。三个选项对应的策略第一个是Checkout Windows-style, commit Unix-style line endings检出时把LF转成CRLF提交时把CRLF转回LF。这是Windows平台推荐选项适合大多数团队尤其适合团队里有跨平台协作、不同人使用不同操作系统的情况。第二个是Checkout as-is, commit Unix-style line endings检出时不转换提交时转LF。适合你确定所有代码都在Windows上使用且团队内没人用其他系统的情况。第三个是Checkout as-is, commit as-is完全不转换。适合纯Linux/macOS团队Windows用户选了大概率踩坑。我见过的绝大多数翻车案例都出现在团队里有Linux和Windows两个平台的场景但有人选了“不转换”。结果Windows同事提交的代码被Git自动把CRLF转成LF后再入库Linux同事一拉取看到的就是一整个文件被标记为改动。所以我的建议是除非你百分百确定自己的仓库只会在单一平台使用否则就选第一个官方推荐项。这个选项选对之后后续的.gitattributes规则和.editorconfig都是在它基础上的微调。3.4 终端模拟器与HTTPS后端决定了你之后在终端里的体感换行符之后是Configuring the terminal emulator to use with Git Bash。这里两个选项Use MinTTY默认选项。MinTTY是一个专门为终端优化的模拟器支持窗口缩放、文本选择、右键粘贴等更舒服的操作是目前Git Bash的默认体验。Use Windows default console window用Windows自带的控制台宿主也就是传统的黑窗口cmd风格。这两个选择不影响Git功能本身纯粹是使用体验的差别。我是MinTTY的忠实用户因为它的CtrlV粘贴、鼠标选中即复制、滚动缓冲这几个特性都做得比Windows默认控制台舒服。如果你习惯Windows Terminal也可以选择Windows default console window然后在Windows Terminal的配置文件里添加Git Bash作为Profile两者可以共存。总之这个选项没有对错按个人喜好来。接着是Choosing the HTTPS transport backend两个选项Use the OpenSSL library使用OpenSSL作为HTTPS传输后端兼容性最广尤其是连接公司自建GitLab时某些自签名证书的信任配置更灵活。Use the native Windows Secure Channel library使用Windows原生凭据库好处是可以通过Windows凭据管理器记住公司代理或私有仓库的账号密码和系统集成更深。我用过一个判断标准如果你主要连GitHub、Gitee这些公开平台两个都无所谓如果你经常连公司内部GitLab并且需要走HTTPS认证选Windows Secure Channel体验更顺滑。但如果你之前用OpenSSL配置过自定义证书请保持现状不要随便切换否则可能出现SSL certificate problem的报错。3.5 收尾阶段的额外选项credential manager、pull策略与符号链接最后几屏的选项很容易被忽略但影响也不小。Configuring extra options有三个勾选Enable file system caching开启文件系统缓存。这个建议勾上能显著提升Git在Windows上的性能尤其是仓库文件很多的时候。Enable Git Credential Manager启用凭据管理器。建议勾选。有了它HTTPS方式clone私有仓库后第一次输入账号密码会被安全存储在Windows凭据管理器里之后无需重复输入。这是个能省掉很多重复操作的选项。Enable symbolic links启用符号链接。这里我要说清楚Windows创建符号链接通常需要管理员权限而这个选项只是允许Git识别仓库里的符号链接不代表你可以随意创建。除非你有明确需求否则不建议勾选因为如果所在仓库包含符号链接但当前用户权限不足反而容易在检出时报权限错误。最后是Configuring experimental options默认是空的这些实验特性不要碰。再往后会看到Enable built-in file system monitor之类的新选项老规矩非实验性需求一律保持默认。装完重启一下终端或者整个系统安装阶段就完成了。4. 装完不等于配好Git Bash、身份配置与优先级4.1 Git Bash、Git CMD与Git GUI的分工安装完成后开始菜单里会出现几个新程序很多新手搞不清它们的分工Git Bash这是在Windows上运行Git命令的推荐终端。它模拟了一个类Unix环境支持ls、cd、pwd这些命令路径规则也更接近Linux。我日常99%的Git操作都在Git Bash里完成。Git CMD用Windows命令提示符风格运行Git命令路径规则和CMD一致。如果你已经接受PowerShell作为主力终端可以不怎么碰它。Git GUI一个基础的图形化界面可以完成提交、查看历史等操作。功能覆盖很有限长期使用不推荐但它作为临时查看历史或处理冲突的“备胎”还算合格。这里要纠正一个常见误解装了Git Bash不等于“能像Linux一样跑所有命令”。Git Bash只是提供了Git工具链和少量Unix工具如grep、sed、awk并不是完整的Linux模拟环境。指望在Git Bash里安装Python包、运行Docker命令那是方向错了。4.2 user.name与user.email提交记录里的身份标记安装完成后第一件事不是去clone代码而是告诉Git“你是谁”。这个身份会写进每一次commit记录里团队协作时别人能通过它知道提交是谁做的。在Git Bash里执行git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com名字建议用真实姓名或者团队统一的工号格式邮箱建议使用和代码托管平台Gitee、GitHub、GitLab一致的邮箱。这样平台上的提交记录就能正确关联到你的账号头像和贡献图。很多新手在这步嫌麻烦直接跳过结果提交记录里显示的全是一串乱码或者userDESKTOP-XXXX这种默认值后期再改历史记录非常痛苦。顺便提一个细节邮箱不要乱填因为公网仓库里的提交邮箱是公开可见的。注重隐私的人可以用平台提供的隐私邮箱功能比如GitHub的用户名users.noreply.github.com。Gitee也支持类似的设置在账号设置里可以开启。4.3 配置优先级system、global、local三层逻辑git config的配置作用域分三层理解这一点对排查问题很有帮助system系统级影响这台机器上的所有用户和所有仓库。配置文件在C:\Program Files\Git\etc\gitconfig。global当前用户级影响当前用户的所有仓库。配置文件在C:\Users\你的用户名\.gitconfig。local仓库级只影响当前仓库。配置文件在仓库目录下的.git\config。查看配置时可以用git config --list git config --system --list git config --global --list git config --local --list修改时用git config --global、git config --system、git config --local分别指定层级。默认情况下local配置会覆盖globalglobal会覆盖system。实际工作中最常遇到的场景是同事在某个仓库里配置了和全局不同的邮箱导致提交记录显示的名字不对。这时候就用上面几条命令逐层查看很快能定位。我还有一个建议把默认分支名从master改成main这是当前社区的主流约定。安装向导新版通常会让你在安装时选择默认分支名如果当时没选可以执行git config --global init.defaultBranch main这样以后执行git init时默认创建的是main分支而不是master和Gitee、GitHub上新建仓库的默认分支名保持一致。5. 安装验证与第一个完整实操闭环5.1 三种方式验证安装版本、路径与组件完整性配置完成后先验证安装结果。打开Git Bash依次执行下面几条命令git --version which git git config --global --listgit --version会显示当前版本号比如git version 2.52.1.windows.1。which git会显示Git可执行文件的路径如果在/usr/bin/git下就对了。git config --global --list会列出刚才配置的user.name和user.email确认信息无误。还有一步容易被忽略验证ssh命令是否可用。在Git Bash里执行ssh -V正常会输出类似OpenSSH_for_Windows_8.6p1的版本信息。Git for Windows自带了一个OpenSSH客户端这就是后面生成SSH密钥要用到的工具。如果这条命令报command not found说明你的安装有问题大概率是组件选择时把SSH相关组件去掉了这种属于极少见情况。5.2 生成SSH密钥并配置到Gitee一劳永逸的免密方案很多教程推荐新手用HTTPS方式clone仓库输一次账号密码后凭据管理器会记住。但对于需要频繁推送的开发者我更推荐直接用SSH协议。SSH密钥配对一次后终身免密而且Gitee、GitHub都支持。打开Git Bash执行ssh-keygen -t ed25519 -C 你的邮箱example.com一路回车密钥默认保存到~/.ssh/id_ed25519。这里如果提示是否设置passphrase可以留空也可以设一个。我个人的建议是公司电脑上可以设置一个防止别人拿到你的密钥文件后直接冒充你推送代码。然后用cat命令查看公钥cat ~/.ssh/id_ed25519.pub你会看到一串以ssh-ed25519开头的长字符串这就是公钥。复制它登录Gitee进入设置 - SSH公钥把内容粘贴保存。标题可以随便写比如“我的Windows开发机”。验证是否配置成功ssh -T gitgitee.com如果看到Hi 用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.说明密钥生效了。这里要提醒一个坑如果之前用过RSA算法生成过密钥Gitee可能同时绑定了多个公钥不影响使用。但2026年OpenSSH已经默认禁用ssh-rsa算法新生成的密钥强烈建议用ed25519不要再用rsa 2048那套老配置。5.3 从clone到首次commit把整个链路走通密钥配好后从一个实际仓库走一遍完整链路。先在Gitee上新建一个测试仓库不要勾选“使用README初始化仓库”这样得到一个空仓库。按页面提示执行git clone gitgitee.com:你的用户名/测试仓库.git cd 测试仓库 echo # 测试项目 README.md git statusgit status会显示README.md是未跟踪状态。接下来添加到暂存区并提交git add README.md git commit -m docs: 初始化项目这里commit -m就是提交说明建议遵循类型: 描述的格式比如fix: 修复登录超时问题、feat: 新增用户中心页面。这是团队协作的规范养成习惯对后面看历史记录非常友好。如果提交完发现说明写错了可以用git commit --amend修改最近一次提交的说明。注意这个命令会改写提交历史如果是已推送到远程的提交不要随意使用除非你确定自己在做什么。最后推送到远程git push -u origin main完整跑通这个流程说明你的Git环境从安装到配置到认证全部正常可以正式投入开发了。6. 高频故障排查与边界认知6.1 “git不是内部或外部命令”的完整排查链路这是所有Git报错里最常见的。出现这个提示意味着系统在PATH里找不到git可执行文件。按以下链路排查。第一步确认安装完成且没有在安装时选择“仅从Git Bash使用”。打开系统设置搜索“环境变量”查看系统变量里有没有Git的安装路径典型的是C:\Program Files\Git\cmd。没有就手动添加。第二步检查是否修改过安装目录。如果你安装时改到了D盘记得把D:\你的路径\Git\cmd加进PATH同时确认该路径下确实有git.exe。第三步改完PATH后必须重启终端最好是注销或者重启一次系统因为环境变量的读取发生在进程启动时旧终端不会自动刷新。第四步在CMD里执行where git看输出路径是否出现在你安装的目录下。如果有多个路径说明系统里存在多个Git版本PATH顺序靠前的优先生效容易造成版本混乱。我之前就遇到过同事电脑里有旧版Git和IDE内置Git抢环境变量的情况排查了很久才定位。6.2 fatal: not a git repository其实不是安装故障fatal: not a git repository (or any of the parent directories): .git这个报错本质上不是安装问题而是命令执行位置不对。Git的命令必须在仓库内执行仓库的标志就是根目录下有一个.git文件夹或者一个.git文件用于指向实际目录。如果你遇到这个报错先执行pwd看当前在哪个目录再执行ls -a看看有没有.git。如果没有说明你还没进入仓库。用cd进入仓库目录后再执行就正常了。我见过很多人一看到命令行报错就怀疑自己安装有问题其实这个报错的排查成本只有十秒钟。6.3 与IDE、TortoiseGit等周边工具的集成匹配IDEA和VS Code都能自动检测Git安装位置。如果IDE提示找不到Git去设置里手动指定git.exe的路径即可。IDEA在Settings - Version Control - GitVS Code在设置 - git.path。这里有个2026年值得注意的点新版Git for Windows默认同时安装了32位和64位版本的情况已经很少见但如果你之前手动覆盖过PATHIDE里指向的版本可能不是你实际安装的版本。建议在IDE的终端里执行git --version确认一下。说到git小乌龟TortoiseGit这是很多Windows老用户喜欢的图形化Git客户端。装小乌龟时要注意版本位数必须和系统一致64位系统装64位版。另一个关键点TortoiseGit需要自己去填SSH客户端路径默认指向C:\Program Files\Git\usr\bin\ssh.exe。如果填错clone和push都会报连接错误。我之前帮一个同事排查他小乌龟一直提示Could not read from remote repository最后发现是SSH客户端路径指向了Git默认安装的另一个目录因为当时安装Git时改了安装路径小乌龟没更新关联。6.4 安装完成后建议立刻建立的几个习惯最后分享几个我踩过多次坑之后沉淀下来的习惯。第一全平台全部使用SSH协议不要混着用HTTPS和SSH。混用的后果是同一个仓库可能缓存了两套凭据一旦密码改了经常莫名报认证失败。第二.gitignore文件一定要在项目初始化时就建好。Windows开发环境下至少要忽略bin/、obj/、.idea/、.vscode/、node_modules/这些目录。否则第一次git add .可能把一堆依赖文件和编译产物提交进仓库后面清理非常麻烦。第三提交信息别偷懒。至少写清楚“做了什么”最好再加“为什么这么做”。我自己团队里要求的格式是类型: 简述比如fix: 修复订单金额溢出问题。这个习惯在review代码时救过很多次场。第四仓库结构层面的安全红线也要知道不要把.git目录暴露到Web服务可以访问的路径下。之前有一种常见的源码泄露方式就是Web目录里能直接访问.git文件夹别人通过工具就能把整个仓库历史下载下来。这不是Git本身的问题而是部署配置的问题但作为开发者用Git管理项目的同时要有这条安全红线意识。最后再说说命令熟手有时候也会忽略的git worktree。这个命令可以让你在同一台机器上同时检出同一个仓库的多个分支到不同目录适合需要同时调试两个分支的场景。安装好Git之后它默认就可用不需要额外配置。它的价值在于你不再需要用git stash把当前工作区藏起来再切分支直接在工作区旁边新建一个目录处理另一个分支就行。新手阶段可能用不上但知道有这个东西等到需要的时候能省下大量切换上下文的时间。总结起来就是一句话Git安装这件事真正的分水岭不是“装没装上”而是“装完之后你懂不懂每个配置在替你做什么”。希望这篇把安装阶段和首次配置阶段讲透之后你能少走几次弯路。
Windows安装Git完整教程：避开PATH、换行符、SSH三大坑
每次帮新同事配开发环境我都会发现一个规律越是觉得“装软件这种小事不用教”的人越容易在Git安装上翻车。2026年了Git的Windows安装向导表面上还是“一路Next”的风格但中间藏着好几个会影响你未来一两年开发体验的选项——PATH怎么选、换行符怎么处理、默认编辑器用什么、HTTPS后端走哪套协议。选错了当时没感觉等你用IDE提交代码时看见满屏diff、或者终端里冒出一堆莫名其妙的fatal报错才会意识到问题早在安装那一步就埋下了。所以这篇我决定把安装过程拆成“能对上号”的图文级详解从下载渠道和版本选择开始到安装向导每一屏的真实含义再到装完后的初始化配置、SSH密钥生成、第一次完整提交闭环最后聊透几个高频报错。不管你是刚转行准备系统学Git的新人还是要帮团队做环境标准化、被同事反复问“为什么我clone不了”的救火队员这篇都能直接照着操作。1. 为什么2026年了Git安装依然值得单独写一篇1.1 我看到的安装误区一路Next的代价先讲一个几乎每年都会遇到的例子。之前帮一个做前端的朋友排查问题他打开终端敲git status屏幕提示fatal: not a git repository。他以为是Git坏了卸载重装了三遍还是老样子。后来我看了一眼他的工作目录里面根本没有.git文件夹——他站在一个普通文件夹里执行Git命令那当然会报这个错。这个例子说明一个问题很多人看安装教程只看了前半段“双击安装包、下一步、完成”却没理解安装完之后Git的运行逻辑。安装Git确实不难两分钟就能装完但安装不等于可用更不等于好用。难的是理解安装向导里那些英文选项到底在决定什么以及装完之后如何让Git和你的IDE、你的代码托管平台、你的团队协作方式真正配合起来。我一直跟团队里的人说安装Git这件事30%是下载和点击70%是配置和验证。这篇教程会把那70%的坑提前替你踩平。1.2 安装向导早已不是“双击下一步”那么简单Git for Windows的安装向导整体框架保持了多年稳定但选项一直在增加。早期版本纠结的是“要不要装Git GUI”后来加入了换行符转换、终端模拟器选择再后来又增加了Git LFS、HTTPS后端、符号链接支持、实验性文件系统监视器等选项。到2026年安装器本身已经不只是“装一个命令行工具”而是“为你的开发环境做一次系统级配置”。这些选项背后代表的是不同的使用习惯和协作协议。举个最典型的例子换行符转换。Windows下文件默认是CRLF结尾Linux和macOS是LF结尾。同一份代码在不同系统之间来回传递如果转换策略设置不当git diff会把整个文件都标记为修改那种“我明明只改了一行为什么diff显示几百行变化”的经典问题根子就在安装时那个不起眼的line ending选项上。所以别再觉得安装教程没有技术含量这一套东西真正吃透的人排查问题的速度会快很多。1.3 这篇教程覆盖的范围与阅读建议这篇教程以Windows为主线因为绝大多数刚接触Git的读者都在Windows环境里工作。macOS用户我会在下载环节单独说两句Linux用户一般用包管理器三行命令的事。全文按真实操作顺序推进先讲怎么选版本、怎么下载、怎么校验文件完整性再逐屏拆解安装向导的每个选项告诉你选什么、为什么装完之后进入初始化配置阶段重点讲user.name、user.email和配置优先级然后走一遍“生成SSH密钥、配置到Gitee、clone仓库、首次提交”的完整闭环最后是高频故障排查。我的建议是如果你是完全没装过Git的小白从头到尾按顺序走如果你已经装好但平时用起来总有些别扭可以直接跳到第三章和第四章大概率能找到答案如果你是团队里负责带新人的那个人建议重点看第三、四章把环境标准化的逻辑讲给新人听。2. 下载环节官网渠道、版本判断与文件校验2.1 官网下载与版本命名规则Git的官方网站是git-scm.com这是唯一权威下载渠道。我见过不少朋友在搜索引擎里搜“Git下载”点进了第三方下载站结果装了一堆捆绑软件还下载到旧版本。2026年的Git稳定版已经走到2.5x时代版本号格式是2.x.x从2.47开始已经支持了很多新特性。判断版本新旧很简单年份越近小版本号越大功能越完整。进入官网后页面会自动根据操作系统显示对应的下载按钮。Windows用户会看到两种选择64-bit Git for Windows Setup和32-bit Git for Windows Setup。除非你的电脑还是十几年前的老古董否则一律选64位。还有一个Portable版本这是便携版不需要安装解压就能用适合放在U盘里临时用但不适合作为日常开发环境因为它的上下文菜单集成和环境变量配置都受限制。macOS用户可以直接下载macOS安装包也可以通过Homebrew安装brew install git。Linux用户更简单Debian系用apt install gitRed Hat系用yum install git而且仓库里的版本往往已经很新。这里我多说一句Linux系统包里带的Git版本一般够用不需要为了追新版本去手动编译源码浪费那个时间没必要。2.2 官网下载慢的应对方案Git官网服务器在海外部分地区的网络环境下下载速度确实不理想。如果你遇到这个问题优先选择国内高校或云厂商的镜像站。常用的镜像有清华开源软件镜像站、阿里云开发者社区镜像站、腾讯软件源等在镜像站里搜索git-for-windows会看到和官网对应的安装包文件列表。用镜像下载时要注意两个细节第一认准Git-x.x.x-64-bit.exe这类完整安装包文件不同镜像站的目录命名略有差别但exe文件不会搞错第二下载完成后看一眼文件大小Git for Windows完整安装包一般在60MB到70MB之间。如果下载下来的文件只有几十KB或者几MB那肯定是下载到了错误的文件比如某些镜像站会额外提供不带自带Git LFS的精简版本。我在实际工作中发现很多同事下载失败其实不是网络问题而是从镜像站下载了一个MinGit精简包——那个只包含命令行工具没有Git Bash、没有右键集成装完之后体验残缺。所以下载前一定看清文件名。2.3 用SHA-256数字指纹验证安装包完整性这一步很多人会跳过但我觉得值得花十秒钟做一下。官网每个版本都会提供SHA-256哈希值下载完成后可以手动计算文件的哈希值进行比对。Windows 10/11自带certutil命令certutil -hashfile C:\Users\你的用户名\Downloads\Git-x.x.x-64-bit.exe SHA256把输出的64位十六进制字符串和官网上标注的哈希值对比一致就说明文件没有损坏、没有被植入任何东西。我之所以强调这一步是因为Git安装包会被杀毒软件和安全工具重点关注偶尔会出现下载过程中被杀软拦截导致文件不完整的情况。哈希校验能一次性排除掉“文件损坏”和“下载不完整”这两类问题后面安装时少折腾很多。3. Windows安装向导逐屏拆解每个选项背后的真实影响3.1 组件勾选哪些必须选哪些可以忽略双击安装包后第一屏是GPL许可证说明直接Next。第二屏是安装目录选择默认是C:\Program Files\Git。我给所有团队成员的建议都是保持默认不要把Git装到D盘自定义路径。原因很简单Git体积只有两三百MB不存在“占用C盘空间”的担忧一旦改了路径后续IDEA、VS Code、GitHub Desktop等工具自动检测Git时可能找不到还得手动去指定路径徒增麻烦。真正需要认真看的是Select Components这一屏。界面里会有几个勾选项我逐个说Additional icons是否创建桌面图标。无所谓后面基本不会从桌面图标启动Git不勾也不影响任何功能。Windows Explorer integration这个建议勾选。它会在右键菜单里加入Git GUI Here和Git Bash Here两个入口。这两个右键入口是Windows下使用Git最舒服的方式没有之一。你想在哪个目录执行Git命令右键就能打开一个已经定位到该目录的终端。Associate .git configuration files with default editor把.gitconfig等配置文件和默认编辑器关联。建议勾上否则以后打开Git配置文件时会被系统用记事本之类不明不白的程序接管。Associate .sh files with default editor把.sh脚本关联到默认编辑器。这个也建议勾上Windows上处理脚本文件时会方便一些。Git LFSLarge File Storage如果你要管理超过100MB的大文件或者仓库里涉及设计稿、二进制资源建议勾选。不勾也不影响常规代码仓库后面需要时随时可以用git lfs install补齐。Scalar这是微软参与的一个性能优化工具对大型仓库有加速效果。如果你平时只是做一些小型项目可以不装如果在一个巨大的monorepo里工作装上没坏处。3.2 PATH环境变量与默认编辑器直接影响日常操作习惯的两个选项Select Components之后是Select Start Menu Folder默认就行。接着进入我认为整个安装过程中最关键的两屏。第一屏是Choosing the default editor used by Git。默认选项是Vim新手的“劝退重灾区”——因为执行git commit需要填写提交说明时会打开Vim而很多人不知道如何在Vim里输入并退出卡在终端里不知所措。这里我建议直接选Use Visual Studio Code as Gits default editor。如果你平时不用VS Code选Notepad或者nano也行唯独不要选Vim。选错的话Git照常能用但每次提交都要和Vim搏斗体验非常糟糕。第二屏是Adjusting your PATH environment三个单选项Only use Git from Git Bash最保守的选项Git命令只在Git Bash里可用IDEA、VS Code这些工具很可能找不到git命令。只推荐对系统安全有极端要求的环境。Recommended把Git核心目录加入系统PATH命令在Git Bash、命令提示符、PowerShell以及各种IDE里都能直接使用。这是官方推荐也是绝大多数人的正确选择。Use Git and optional Unix tools from Command Prompt不仅加PATH还会把一批Unix命令ls、find、grep等注入系统目录。看起来很方便但这些命令和Windows自带命令存在命名冲突风险比如Windows系统目录里也有find.exe装了之后谁生效完全取决于PATH顺序容易制造莫名奇妙的兼容问题。我的建议非常明确选第二项Recommended不要为了省一两个Linux命令去冒冲突的险。3.3 换行符转换新手最容易埋雷、老手也常翻车的选项接下来是Configuring the line ending conversions三个单选选项我把它称为“整个安装向导里最需要理解的一屏”。先说背景Windows系统里文本文件默认用回车换行CRLF\r\n结尾而Linux和macOS系统用换行LF\n结尾。Git仓库里存储的行尾符格式是LF。当你把仓库克隆到Windows时Git需要决定工作区文件用什么行尾符当你提交时又需要决定把工作区的行尾符转回LF再入库。这个转换过程选错策略就会出现“我只改了一行但diff显示整个文件都变了”的灵异事件。三个选项对应的策略第一个是Checkout Windows-style, commit Unix-style line endings检出时把LF转成CRLF提交时把CRLF转回LF。这是Windows平台推荐选项适合大多数团队尤其适合团队里有跨平台协作、不同人使用不同操作系统的情况。第二个是Checkout as-is, commit Unix-style line endings检出时不转换提交时转LF。适合你确定所有代码都在Windows上使用且团队内没人用其他系统的情况。第三个是Checkout as-is, commit as-is完全不转换。适合纯Linux/macOS团队Windows用户选了大概率踩坑。我见过的绝大多数翻车案例都出现在团队里有Linux和Windows两个平台的场景但有人选了“不转换”。结果Windows同事提交的代码被Git自动把CRLF转成LF后再入库Linux同事一拉取看到的就是一整个文件被标记为改动。所以我的建议是除非你百分百确定自己的仓库只会在单一平台使用否则就选第一个官方推荐项。这个选项选对之后后续的.gitattributes规则和.editorconfig都是在它基础上的微调。3.4 终端模拟器与HTTPS后端决定了你之后在终端里的体感换行符之后是Configuring the terminal emulator to use with Git Bash。这里两个选项Use MinTTY默认选项。MinTTY是一个专门为终端优化的模拟器支持窗口缩放、文本选择、右键粘贴等更舒服的操作是目前Git Bash的默认体验。Use Windows default console window用Windows自带的控制台宿主也就是传统的黑窗口cmd风格。这两个选择不影响Git功能本身纯粹是使用体验的差别。我是MinTTY的忠实用户因为它的CtrlV粘贴、鼠标选中即复制、滚动缓冲这几个特性都做得比Windows默认控制台舒服。如果你习惯Windows Terminal也可以选择Windows default console window然后在Windows Terminal的配置文件里添加Git Bash作为Profile两者可以共存。总之这个选项没有对错按个人喜好来。接着是Choosing the HTTPS transport backend两个选项Use the OpenSSL library使用OpenSSL作为HTTPS传输后端兼容性最广尤其是连接公司自建GitLab时某些自签名证书的信任配置更灵活。Use the native Windows Secure Channel library使用Windows原生凭据库好处是可以通过Windows凭据管理器记住公司代理或私有仓库的账号密码和系统集成更深。我用过一个判断标准如果你主要连GitHub、Gitee这些公开平台两个都无所谓如果你经常连公司内部GitLab并且需要走HTTPS认证选Windows Secure Channel体验更顺滑。但如果你之前用OpenSSL配置过自定义证书请保持现状不要随便切换否则可能出现SSL certificate problem的报错。3.5 收尾阶段的额外选项credential manager、pull策略与符号链接最后几屏的选项很容易被忽略但影响也不小。Configuring extra options有三个勾选Enable file system caching开启文件系统缓存。这个建议勾上能显著提升Git在Windows上的性能尤其是仓库文件很多的时候。Enable Git Credential Manager启用凭据管理器。建议勾选。有了它HTTPS方式clone私有仓库后第一次输入账号密码会被安全存储在Windows凭据管理器里之后无需重复输入。这是个能省掉很多重复操作的选项。Enable symbolic links启用符号链接。这里我要说清楚Windows创建符号链接通常需要管理员权限而这个选项只是允许Git识别仓库里的符号链接不代表你可以随意创建。除非你有明确需求否则不建议勾选因为如果所在仓库包含符号链接但当前用户权限不足反而容易在检出时报权限错误。最后是Configuring experimental options默认是空的这些实验特性不要碰。再往后会看到Enable built-in file system monitor之类的新选项老规矩非实验性需求一律保持默认。装完重启一下终端或者整个系统安装阶段就完成了。4. 装完不等于配好Git Bash、身份配置与优先级4.1 Git Bash、Git CMD与Git GUI的分工安装完成后开始菜单里会出现几个新程序很多新手搞不清它们的分工Git Bash这是在Windows上运行Git命令的推荐终端。它模拟了一个类Unix环境支持ls、cd、pwd这些命令路径规则也更接近Linux。我日常99%的Git操作都在Git Bash里完成。Git CMD用Windows命令提示符风格运行Git命令路径规则和CMD一致。如果你已经接受PowerShell作为主力终端可以不怎么碰它。Git GUI一个基础的图形化界面可以完成提交、查看历史等操作。功能覆盖很有限长期使用不推荐但它作为临时查看历史或处理冲突的“备胎”还算合格。这里要纠正一个常见误解装了Git Bash不等于“能像Linux一样跑所有命令”。Git Bash只是提供了Git工具链和少量Unix工具如grep、sed、awk并不是完整的Linux模拟环境。指望在Git Bash里安装Python包、运行Docker命令那是方向错了。4.2 user.name与user.email提交记录里的身份标记安装完成后第一件事不是去clone代码而是告诉Git“你是谁”。这个身份会写进每一次commit记录里团队协作时别人能通过它知道提交是谁做的。在Git Bash里执行git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com名字建议用真实姓名或者团队统一的工号格式邮箱建议使用和代码托管平台Gitee、GitHub、GitLab一致的邮箱。这样平台上的提交记录就能正确关联到你的账号头像和贡献图。很多新手在这步嫌麻烦直接跳过结果提交记录里显示的全是一串乱码或者userDESKTOP-XXXX这种默认值后期再改历史记录非常痛苦。顺便提一个细节邮箱不要乱填因为公网仓库里的提交邮箱是公开可见的。注重隐私的人可以用平台提供的隐私邮箱功能比如GitHub的用户名users.noreply.github.com。Gitee也支持类似的设置在账号设置里可以开启。4.3 配置优先级system、global、local三层逻辑git config的配置作用域分三层理解这一点对排查问题很有帮助system系统级影响这台机器上的所有用户和所有仓库。配置文件在C:\Program Files\Git\etc\gitconfig。global当前用户级影响当前用户的所有仓库。配置文件在C:\Users\你的用户名\.gitconfig。local仓库级只影响当前仓库。配置文件在仓库目录下的.git\config。查看配置时可以用git config --list git config --system --list git config --global --list git config --local --list修改时用git config --global、git config --system、git config --local分别指定层级。默认情况下local配置会覆盖globalglobal会覆盖system。实际工作中最常遇到的场景是同事在某个仓库里配置了和全局不同的邮箱导致提交记录显示的名字不对。这时候就用上面几条命令逐层查看很快能定位。我还有一个建议把默认分支名从master改成main这是当前社区的主流约定。安装向导新版通常会让你在安装时选择默认分支名如果当时没选可以执行git config --global init.defaultBranch main这样以后执行git init时默认创建的是main分支而不是master和Gitee、GitHub上新建仓库的默认分支名保持一致。5. 安装验证与第一个完整实操闭环5.1 三种方式验证安装版本、路径与组件完整性配置完成后先验证安装结果。打开Git Bash依次执行下面几条命令git --version which git git config --global --listgit --version会显示当前版本号比如git version 2.52.1.windows.1。which git会显示Git可执行文件的路径如果在/usr/bin/git下就对了。git config --global --list会列出刚才配置的user.name和user.email确认信息无误。还有一步容易被忽略验证ssh命令是否可用。在Git Bash里执行ssh -V正常会输出类似OpenSSH_for_Windows_8.6p1的版本信息。Git for Windows自带了一个OpenSSH客户端这就是后面生成SSH密钥要用到的工具。如果这条命令报command not found说明你的安装有问题大概率是组件选择时把SSH相关组件去掉了这种属于极少见情况。5.2 生成SSH密钥并配置到Gitee一劳永逸的免密方案很多教程推荐新手用HTTPS方式clone仓库输一次账号密码后凭据管理器会记住。但对于需要频繁推送的开发者我更推荐直接用SSH协议。SSH密钥配对一次后终身免密而且Gitee、GitHub都支持。打开Git Bash执行ssh-keygen -t ed25519 -C 你的邮箱example.com一路回车密钥默认保存到~/.ssh/id_ed25519。这里如果提示是否设置passphrase可以留空也可以设一个。我个人的建议是公司电脑上可以设置一个防止别人拿到你的密钥文件后直接冒充你推送代码。然后用cat命令查看公钥cat ~/.ssh/id_ed25519.pub你会看到一串以ssh-ed25519开头的长字符串这就是公钥。复制它登录Gitee进入设置 - SSH公钥把内容粘贴保存。标题可以随便写比如“我的Windows开发机”。验证是否配置成功ssh -T gitgitee.com如果看到Hi 用户名! Youve successfully authenticated, but GITEE.COM does not provide shell access.说明密钥生效了。这里要提醒一个坑如果之前用过RSA算法生成过密钥Gitee可能同时绑定了多个公钥不影响使用。但2026年OpenSSH已经默认禁用ssh-rsa算法新生成的密钥强烈建议用ed25519不要再用rsa 2048那套老配置。5.3 从clone到首次commit把整个链路走通密钥配好后从一个实际仓库走一遍完整链路。先在Gitee上新建一个测试仓库不要勾选“使用README初始化仓库”这样得到一个空仓库。按页面提示执行git clone gitgitee.com:你的用户名/测试仓库.git cd 测试仓库 echo # 测试项目 README.md git statusgit status会显示README.md是未跟踪状态。接下来添加到暂存区并提交git add README.md git commit -m docs: 初始化项目这里commit -m就是提交说明建议遵循类型: 描述的格式比如fix: 修复登录超时问题、feat: 新增用户中心页面。这是团队协作的规范养成习惯对后面看历史记录非常友好。如果提交完发现说明写错了可以用git commit --amend修改最近一次提交的说明。注意这个命令会改写提交历史如果是已推送到远程的提交不要随意使用除非你确定自己在做什么。最后推送到远程git push -u origin main完整跑通这个流程说明你的Git环境从安装到配置到认证全部正常可以正式投入开发了。6. 高频故障排查与边界认知6.1 “git不是内部或外部命令”的完整排查链路这是所有Git报错里最常见的。出现这个提示意味着系统在PATH里找不到git可执行文件。按以下链路排查。第一步确认安装完成且没有在安装时选择“仅从Git Bash使用”。打开系统设置搜索“环境变量”查看系统变量里有没有Git的安装路径典型的是C:\Program Files\Git\cmd。没有就手动添加。第二步检查是否修改过安装目录。如果你安装时改到了D盘记得把D:\你的路径\Git\cmd加进PATH同时确认该路径下确实有git.exe。第三步改完PATH后必须重启终端最好是注销或者重启一次系统因为环境变量的读取发生在进程启动时旧终端不会自动刷新。第四步在CMD里执行where git看输出路径是否出现在你安装的目录下。如果有多个路径说明系统里存在多个Git版本PATH顺序靠前的优先生效容易造成版本混乱。我之前就遇到过同事电脑里有旧版Git和IDE内置Git抢环境变量的情况排查了很久才定位。6.2 fatal: not a git repository其实不是安装故障fatal: not a git repository (or any of the parent directories): .git这个报错本质上不是安装问题而是命令执行位置不对。Git的命令必须在仓库内执行仓库的标志就是根目录下有一个.git文件夹或者一个.git文件用于指向实际目录。如果你遇到这个报错先执行pwd看当前在哪个目录再执行ls -a看看有没有.git。如果没有说明你还没进入仓库。用cd进入仓库目录后再执行就正常了。我见过很多人一看到命令行报错就怀疑自己安装有问题其实这个报错的排查成本只有十秒钟。6.3 与IDE、TortoiseGit等周边工具的集成匹配IDEA和VS Code都能自动检测Git安装位置。如果IDE提示找不到Git去设置里手动指定git.exe的路径即可。IDEA在Settings - Version Control - GitVS Code在设置 - git.path。这里有个2026年值得注意的点新版Git for Windows默认同时安装了32位和64位版本的情况已经很少见但如果你之前手动覆盖过PATHIDE里指向的版本可能不是你实际安装的版本。建议在IDE的终端里执行git --version确认一下。说到git小乌龟TortoiseGit这是很多Windows老用户喜欢的图形化Git客户端。装小乌龟时要注意版本位数必须和系统一致64位系统装64位版。另一个关键点TortoiseGit需要自己去填SSH客户端路径默认指向C:\Program Files\Git\usr\bin\ssh.exe。如果填错clone和push都会报连接错误。我之前帮一个同事排查他小乌龟一直提示Could not read from remote repository最后发现是SSH客户端路径指向了Git默认安装的另一个目录因为当时安装Git时改了安装路径小乌龟没更新关联。6.4 安装完成后建议立刻建立的几个习惯最后分享几个我踩过多次坑之后沉淀下来的习惯。第一全平台全部使用SSH协议不要混着用HTTPS和SSH。混用的后果是同一个仓库可能缓存了两套凭据一旦密码改了经常莫名报认证失败。第二.gitignore文件一定要在项目初始化时就建好。Windows开发环境下至少要忽略bin/、obj/、.idea/、.vscode/、node_modules/这些目录。否则第一次git add .可能把一堆依赖文件和编译产物提交进仓库后面清理非常麻烦。第三提交信息别偷懒。至少写清楚“做了什么”最好再加“为什么这么做”。我自己团队里要求的格式是类型: 简述比如fix: 修复订单金额溢出问题。这个习惯在review代码时救过很多次场。第四仓库结构层面的安全红线也要知道不要把.git目录暴露到Web服务可以访问的路径下。之前有一种常见的源码泄露方式就是Web目录里能直接访问.git文件夹别人通过工具就能把整个仓库历史下载下来。这不是Git本身的问题而是部署配置的问题但作为开发者用Git管理项目的同时要有这条安全红线意识。最后再说说命令熟手有时候也会忽略的git worktree。这个命令可以让你在同一台机器上同时检出同一个仓库的多个分支到不同目录适合需要同时调试两个分支的场景。安装好Git之后它默认就可用不需要额外配置。它的价值在于你不再需要用git stash把当前工作区藏起来再切分支直接在工作区旁边新建一个目录处理另一个分支就行。新手阶段可能用不上但知道有这个东西等到需要的时候能省下大量切换上下文的时间。总结起来就是一句话Git安装这件事真正的分水岭不是“装没装上”而是“装完之后你懂不懂每个配置在替你做什么”。希望这篇把安装阶段和首次配置阶段讲透之后你能少走几次弯路。
