很多人把“安装 Git”当成双击 exe 然后一路 Next 的小事，但我见过太多人三个月后栽在安装时埋下的坑里：提交历史里用户名全是乱码、中文文件名显示成一堆\345\274\240、或者 IDE 死活找不到 Git 可执行文件。这篇是 Git 系列的第一篇，专门解决“从 0 到 1 把 Git 装对”这件事。我会把 Windows、macOS、Linux 三种平台的下载安装路径、安装向导里每一项选择的真实含义、装完必须做的基础配置、以及我踩过和帮别人排过的典型安装问题全部过一遍。
这篇适合所有刚开始接触 Git 的人，也适合那些“装是装了，但从没认真看过安装选项”的同学——如果你打算用 Git 管自己的代码、跟着开源项目学习、或者未来要和别人协作写项目，这十几分钟读下来，能省掉后面大量的折腾时间。
1. 为什么值得认真对待“装 Git”这件事
1.1 安装只是起点，配置才是分水岭
先说个观察。很多人问“Git 怎么装”，实际想问的是“怎么把 GitHub 上的项目下载下来”。但 Git 是一个分布式版本控制系统，它的核心能力是”管理你自己的代码历史”，下载别人的代码只是一个附带功能。所以如果只把它当下载工具，装完之后很快就会遇到各种别扭的时刻：改了文件却不知道怎么看差异、想回退却发现历史一团乱麻、提交之后作者信息全是错的。
真正决定 Git 好不好用的，不是安装包本身，而是装完之后那几分钟的配置。用户信息配置错了，后面每一次提交都会留下不可追溯的脏数据；换行符策略没选对，跨平台协作时会在 diff 里看到满屏的”假改动”；中文文件名的显示配置缺失，会看到一串转义后的八进制乱码。这些都不是 Git 本身的 bug，而是安装阶段没有想清楚。
1.2 下载渠道怎么选：官网、镜像、包管理器
Git 的官方下载站在git-scm.com/downloads，界面简单，各平台入口都在一个页面上。对于大部分国内用户来说，直接访问官方站有时会慢，尤其 Windows 的安装包接近 60MB。这时候可以选择腾讯云、阿里云、华为云这类软件镜像站，它们都会同步 Git for Windows 的最新版本，速度通常比官网快很多。
镜像站下载要注意一个点：认准文件名里的版本号和架构。比如Git-2.47.1-64-bit.exe就是 64 位 Windows 版，Git-2.47.1-32-bit.exe是 32 位版。现在的电脑基本都能跑 64 位，除非你的机器特别老或内存小于 4GB，否则直接选 64 位即可。
macOS 和 Linux 用户则可以考虑另一条路线：用系统生态里的包管理器，比如 Homebrew、apt、dnf。这条路的好处是后续升级方便，一条命令搞定；缺点是版本可能不是最新。Git 这个工具的更新节奏没那么激进，只要不是太旧的版本，日常使用几乎无感。所以我的建议是：桌面端用户直接用官方安装包，命令行为主的用户用包管理器，怎么省事怎么来。
2. Windows 平台：下载源与安装向导的逐项拆解
2.1 下载前要明白“Git for Windows”是什么
Windows 上装的 Git，正式名字叫 Git for Windows，它不是一个简单的命令行工具移植，而是一个完整的环境套件，里面包含：
- 真正的 Git 核心命令（
git开头的那些） - Bash 模拟环境，也就是安装后右键能看到的“Git Bash Here”
- 常用的 Unix 小工具（
ls、grep、sed、awk等） - SSH 客户端、GNU 加密库、证书库等底层依赖
很多人不理解为什么 Git 在 Windows 上要捆绑一个 Bash。原因其实很简单：Git 本身是 Linux 生态里长出来的工具，大量操作习惯都建立在 Shell 环境之上。你在网上看到的很多 Git 教程，命令行里的操作比如mkdir、cd、cat，在 Windows 自带的 CMD 里是另一套写法。Git Bash 把人拉回熟悉的 Unix 环境，这样教程怎么说、你就怎么敲，不会被 Windows 的语法差异打扰。这也是我这么多年一直推荐 Windows 用户在 Git Bash 里学 Git 的原因。
2.2 安装向导里那些“默认选项”的真实含义
Git for Windows 的安装向导其实只有几步，但每一步都不是摆设。以下是我认为必须理解清楚的几个界面。
Select Components（组件选择）：默认勾选基本合理。还有一个容易忽略的选项是“Add a Git Bash Profile to Windows Terminal”，如果你用的是 Windows 11 自带的 Terminal，建议勾上，这样之后可以在终端下拉菜单里直接打开 Git Bash，比右键菜单更顺手。其它比如每日检查更新、把 Git 加入 PATH，默认即可。
Default editor（默认编辑器）：这里默认是 Vim，但我认真劝退新手选 Vim。因为当你执行git commit而没有附带-m参数时，Git 会打开这个编辑器让你填写提交说明。Vim 的退出方式（按Esc，输入:wq）对没接触过的人来说完全是玄学。我见过一个同学卡在 Vim 里半小时出不来，原因就是不知道怎么保存退出。装的时候建议直接选其他选项，如果机器上有 VS Code 就选 VS Code，有 Notepad++ 就选 Notepad++，实在不行选 Nano 也比 Vim 友好。当然，这个选项装完后也可以用命令随时改，不用紧张。
Adjusting your PATH environment（PATH 环境变量）：这是整个安装向导里最关键的决策点。它有三个选项：
Git from the command line and also from 3rd-party software（推荐）：把 Git 的核心命令加入系统 PATH，这样 CMD、PowerShell、各种 IDE 都能调用git命令。Use Git from Git Bash only：只在 Git Bash 里能用，CMD 和 IDE 里无法使用。Use Git and optional Unix tools from the Command Prompt：不仅加入 Git，还把 Unix 工具也暴露给 CMD。这个选项最不推荐，因为它会用 Unix 的find、sort等命令覆盖掉 Windows 同名的系统命令，可能引发奇怪的系统行为。
我只说一句：选第一项。很多 IDE 报“无法检测到 Git”，根源就是装的时候选了第二项。
Line ending conversions（行尾转换策略）：这个选项和跨平台协作有关。Windows 用CRLF作为换行符，macOS/Linux 用LF，如果两边都不转换，Git 会认为每个文件都改了。这儿的三个选项含义分别是：
Checkout Windows-style, commit Unix-style（推荐）：检出代码到 Windows 时自动转成CRLF，提交回仓库时转成LF。这是最常见的推荐配置。Checkout as-is, commit Unix-style：检出时保持原样，提交时转成LF。适合你确定仓库里不会混入CRLF的情况。Checkout as-is, commit as-is：不做任何转换，要求团队所有人自觉使用统一的换行符。
对新手我的建议是：选第一个，别多想。装完后续也可以靠git config core.autocrlf调整策略，我在第 4 章再细讲。
Terminal emulator（终端模拟器）：这里二选一，MinTTY和Windows Console。MinTTY 是 Git for Windows 默认推荐项，支持彩色输出、快捷键更丰富，在 Git Bash 里敲命令的体验好很多。Windows Console 则和旧版终端外观一致，兼容性优先但功能朴素。对日常使用，选 MinTTY 就对了。
Git Credential Manager（凭据管理器）：默认勾选。它的价值在于：当你通过 HTTPS 方式推送代码到 GitHub、GitLab 这类平台时，Git 会弹出登录窗口，输入账号密码或令牌后，凭据会被安全保存，下次操作不再重复输入。如果不装它，每次 push 都可能要求你重新认证，非常折磨。所以这一项务必保留。
其余选项：像 symbolic link 支持、文件系统缓存、实验性功能，保持默认即可。实验性功能我建议不勾，因为那些特性还在打磨，没必要用自己日常环境去试错。
2.3 安装完成后的第一眼检查
装完后桌面不会有快捷方式图标，这是很多人“以为自己没装成功”的原因。实际上你应该做这几步验证：
- 在任意文件夹空白处点击右键，菜单里出现
Open Git Bash here和Open Git GUI here，说明安装成功。 - 打开 Git Bash，输入
git --version，能看到类似git version 2.47.1.windows.1的输出。 - 再输入
which git，能返回一个实际路径，比如/c/Program Files/Git/cmd/git。
这里有一个 Windows 特有的小细节：右键菜单里的 Git Bash Here，打开之后默认就停留在当前目录，这是后续所有仓库操作最常用的入口。我建议从今天开始，凡是和 Git 有关的本地操作，都从这个入口进，而不是去系统搜索框里找 Git Bash 再cd半天。
3. macOS 和 Linux：两条完全不同的安装路径
3.1 macOS：三种方式，优先级怎么排
macOS 用户装 Git 通常有三条路：
Apple 提供的 Command Line Tools（命令行开发者工具）：在终端里执行xcode-select --install，系统会弹窗引导安装。装完自带一个 Git，但版本往往偏旧。优点是系统级集成，缺点是版本落后，而且一些需要新语法特性的命令会提示不支持。
官方 pkg 安装包：从git-scm.com/download/mac下载，双击安装。这种方式会装一个独立的、较新的 Git，并默认放置在一个独立目录，比如/usr/local/git/bin。安装时系统可能提示“未验证的开发者”之类，需要到系统设置的安全性与隐私里允许打开。对不习惯命令行的同学，这条路最直观。
Homebrew：如果日常使用 macOS 已经装了 Homebrew，一条brew install git就能拿到当前稳定版。这也是我个人最推荐的方式，理由只有一个：后续升级方便。brew upgrade git一行搞定，不用重新下载安装包，也不用担心系统残留旧版本。
这里有个常见误区：明明用了brew install git，重启终端后git --version显示的还是旧版。原因通常是系统自带的 Git 路径（/usr/bin/git）被优先搜索到了。可以用which git和type -a git查看顺序，必要时用export PATH="/usr/local/bin:$PATH"或 Homebrew 提示的路径来调整环境变量优先级。如果你不想折腾，最简单的办法是把官方 pkg 和 Homebrew 二选一，不要混装。
3.2 Linux：包管理器命令背后的差异
Linux 发行版众多，命令不尽相同，但思路一致：从官方软件源安装。
Debian / Ubuntu 系：
sudo apt update sudo apt install gitRHEL / CentOS 7 及以下、Fedora 早期版本：
sudo yum install gitFedora、RHEL 8+：
sudo dnf install gitArch / Manjaro：
sudo pacman -S git装完后同样用git --version验证。Linux 下遇到最多的问题是“官方源里的 Git 版本太旧”，比如某些长期支持版系统自带的 Git 可能还在 2.7 甚至更低，很多新特性完全没有。遇到这种情况，可以考虑从源码编译，但我不建议日常用户这么做——编译 Git 会引入大量依赖编译过程，耗时且容易出错。更稳妥的做法是添加第三方源，比如针对 Ubuntu 的 Git PPA（ppa:git-core/ppa），或者直接下载官方编译好的二进制包。对绝大多数日常开发需求来说，系统源里的版本已经够用了。
还有一点提醒：如果你是以 root 用户安装，记得思考一下是否需要给普通用户也做配置。Git 的全局配置存储在用户主目录的~/.gitconfig文件里，root 用户配置的 user.name 和 user.email 不会自动同步到普通用户。多用户共用机器时，最好每个人各自执行一次配置命令，否则两个用户提交的代码会混成同一个身份。
4. 装完先别急着 commit：第一次配置决定后面所有提交
4.1 提交身份：Git 怎么知道“你”是谁
安装完成后第一件事，不是打开 Git 对项目 init，而是告诉 Git 你是谁。执行：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里的--global表示全局生效，写入的是用户主目录下的~/.gitconfig文件。配置完成后的每次提交，Git 都会把这个名字和邮箱写入提交记录，成为历史的一部分。
有人觉得“反正都是自己一个人在写，随便填一个呗”。我不建议这么做，因为提交身份是会长期留在仓库历史里的。如果填错，或者填了别人的信息，后面想去改就要动用git filter-branch之类的大规模历史重写工具，麻烦且危险。最好从第一天就用真实常用、且和你代码托管平台账号一致的邮箱，这样提交记录能正确关联到你的账号上，贡献图才不会乱。
配置验证也很简单：
git config --global --list输出里能看到刚才设置的内容。如果拼错了，重新执行一次配置命令即可，最后一次写入的会覆盖旧值。
4.2 跨平台换行符：为什么别人的项目一克隆就“全改了”
我在第 2 章提到过安装向导里的行尾选项，那是安装层面。装完之后，还可以靠命令再次确认和调整。Windows 用户建议：
git config --global core.autocrlf truemacOS / Linux 用户建议：
git config --global core.autocrlf input这个配置的作用是：true模式在检出文件时把LF转成CRLF，提交时把CRLF转回LF；input模式检出时不做转换，但提交时仍然把CRLF转成LF。简单理解就是：仓库内部永远存LF，保证跨平台一致；工作区的换行符按当前系统的习惯来，Windows 用户编辑文件不会遇到换行符报错，macOS/Linux 用户也不会有多余的转换负担。
这配置没做会怎样？我就见过一个实际案例。一个团队里 Windows 和 macOS 同学各自提交，Windows 同学保存文件时编辑器把换行符全部变成CRLF并提交进仓库，macOS 同学拉下来一看，git diff显示所有文件都变了，实际内容却一行没动。这种“假 diff”会导致 code review 极其痛苦，严重的可能把别人的改动淹没在换行符噪声里。
4.3 中文相关的两个配置：文件名和日志显示
如果你是中文用户，强烈建议执行：
git config --global core.quotepath falseGit 默认会对非 ASCII 的文件名做八进制转义，比如一个叫测试.txt的文件，在git status里会显示成"\346\265\213\350\257\225.txt"，完全没法读。设置core.quotepath false之后，中文文件名能正常显示。这个配置对日常使用体验影响极大，却极少出现在新手教程里。
另外，如果 Git 输出的中文内容出现乱码，通常是终端编码和 Git 的编码不匹配。Git Bash 环境下一般问题不大；如果用系统 CMD，可以尝试把终端代码页切到 UTF-8：chcp 65001。Linux/macOS 终端基本天然支持 UTF-8，很少遇到这类问题。
4.4 安装成功与否的完整验证清单
配置完成后，我建议按这个清单做一轮完整的体检：
git --version—— 能看到版本号，确认命令可用。git config --global --list—— 能看到 user.name、user.email 等核心配置，确认身份无误。- 找一个临时目录，执行
git init，确认生成了.git文件夹，此时 Git 仓库创建成功。 - 在该目录新建一个文件，执行
git add .和git commit -m "first commit"，确认提交成功；再执行git log --oneline，能看到一条提交记录，且作者名和邮箱是你配置的。 - 在项目目录里随便乱改一个文件后执行
git diff，确认中文显示正常、换行符没有产生多余的干扰。
到这里，Git 才算真正装好、配好了。很多教程在这步就收尾，但真实的安装流程中，还有几个高频问题值得单独拿出来讲。
5. 安装之后我经常被问到的几个问题与排查思路
5.1 明明装好了，CMD 里却提示“git 不是内部或外部命令”
这个报错最直接的原因是：安装时 PATH 环境变量没有配置成功，或者安装后没有重启终端。
先确认安装时是否选了“Git from the command line and also from 3rd-party software”。如果选了但依然不行，按Win + R输入sysdm.cpl，打开环境变量设置窗口，在“系统变量”的Path里查找是否有C:\Program Files\Git\cmd这一条。如果存在，问题大概率是当前终端没有重新加载环境变量——CMD 或 PowerShell 启动时读取环境变量，窗口开着就是旧值，关掉重开即可。
如果是 IDE 内嵌终端、或者某些编辑器里报同样错误，则需要重启整个 IDE，让进程重新读取环境变量。
还有一个隐蔽情况：安装了多个版本的 Git，或者手动修改过 PATH 导致C:\Program Files\Git\cmd被其他目录里的git.exe抢占。排查时可以执行where git，Windows 会按 PATH 顺序打印所有匹配到的 git 路径，看看到底是哪一个被优先调用。
5.2 IDE 显示“无法检测到 Git”，但命令行里明明能用
这通常不是安装问题，而是 IDE 默认没有自动找到 Git 的可执行文件。以 IntelliJ 系列为例，在File > Settings > Version Control > Git里，Path to Git executable应该指向C:\Program Files\Git\cmd\git.exe，确保路径正确后点“Test”可以验证。VS Code 则更简单，只要系统 PATH 正确，重启一下 VS Code 就能识别；如果还不行，可以在设置里明确指定git.path。
这个问题的本质是：IDE 不调用 PATH 里的git，而是直接找特定路径，或者依赖启动时的环境变量快照。所以排查思路永远是：先确认命令行git --version正常，再确认 IDE 的 Git 路径配置指向正确的可执行文件，最后重启 IDE。百分之九十的问题都出在这三步之内。
5.3 Git Bash 里中文乱码、命令补全不生效之类的小别扭
中文乱码分两种情况：一种是git status里的中文文件名单显示为转义序列，这个靠第 4 章说的core.quotepath false解决；另一种是终端输出乱码，这个要看 Git Bash 的字体和编码设置。Git Bash 的窗口菜单里选择“Options > Text”，将字符集设为 UTF-8，字体换成中文字体兼容的即可。
关于命令补全，Git Bash 本身已经内置了 git 命令和分支名的 Tab 补全，不需要额外配置。如果你用的是 PowerShell，可以装 posh-git，让提示符里直接显示当前分支和未提交状态。这个属于体验优化，不想折腾也不影响任何实际功能。
5.4 下载慢、中断、校验失败怎么办
Windows 安装包下载慢或中途失败，最简单的办法是换镜像源，前面提到的几个云厂商软件镜像一般都有同步。下载完成后如果担心安装包损坏，可以在官网页面找到 SHA-256 校验值，把本地文件的哈希算出来对比一下。注意：安装包版本不同校验值也不同，务必与该版本对应匹配。
6. 安装过程中的两点个人体会
装 Git 这件事，说实话技术难度很低，真正重要的其实是“理解每个选项在做什么”。安装时随手选错一个，可能在几个月后才以诡异的方式爆发。我在给身边人做技术支持时，见过太多例“提交人是谁都不知道”“一个文件 diff 出一千行”“推不上去一直让输密码”的问题，追根溯源，都是装的时候没有看过选项的含义。
这篇把下载安装和首次配置讲透了，后面 Git 系列我会开始讲真正让这个工具发挥价值的部分：仓库的生命周期、add/commit/log 这组日常命令的使用逻辑、分支管理与合并策略，还有协作场景里最见功底的 pull request 和冲突解决。你可以先把这篇当作一个稳妥的地基，确保自己的 Git 环境是健康的，再往后走就不会被各种莫名其妙的环境问题绊倒。
