聊到 Git 安装这件事，很多新手第一反应是“不就是一直 Next 吗”，但真到自己动手时，经常会在 PATH 配置、换行符转换、默认编辑器、凭证管理器这些选项上卡住。这篇 Git 安装教程会带你把每一个步骤拆开讲清楚，不光是告诉你该点哪个按钮，更重要的是解释每个选项到底是什么意思、选错了会有什么后果、装完以后还要做哪些验证和配置。这篇文章适合所有刚开始接触 Git 的开发者，也适合那些已经装过几次但一直没搞清楚选项含义的人。我把 Windows、macOS、Linux 三种环境下最常见的安装方式都整理了一遍，重点放在 Windows 逐步骤安装，因为大多数新手第一次遇到的就是这个图形化安装向导。
1. 安装前的准备工作与版本选择
1.1 先搞清楚自己处于什么环境
Git 本质上是一个命令行工具，但它在不同操作系统上的安装方式差异很大。Windows 上你拿到的是一个图形化安装包，一步步点下去就能装好；macOS 上可以选择带图形界面的安装包，也可以用系统自带的命令行工具；Linux 上则几乎都是通过包管理器一条命令完成。所以第一步不是急着下载，而是先确认三件事：你的操作系统是什么、系统架构是 64 位还是 32 位、你有没有管理员权限。
大多数现代电脑都是 64 位系统，Windows 10/11 用户只需要认准 64-bit 版本即可。Linux 用户可以打开终端执行uname -m，输出结果是x86_64就代表 64 位，aarch64则是 ARM 架构。macOS 用户还要多留意一点，Apple 芯片和 Intel 芯片的安装包不通用，下载时如果看到arm64和x86_64两个版本，要根据自己的机器选择。装错版本的情况虽然不多，但真遇到的时候往往很难排查，因为错误提示可能要到很后面才出现。
1.2 版本选择：不是越新越好
Git 的版本更新速度不算慢，每隔几个月就会有一个新版本。很多人的习惯是看到新版本就追，但我的建议是，在正式项目环境中优先选择稳定版本，也就是官方页面上标注为大版本里比较成熟的版本。新版本通常会带来新功能和性能优化，但也可能引入一些兼容性调整，比如某些旧脚本依赖的行为发生变化。
如果你是完全的新手，千万不要去下载那些标记为 rc、beta、preview 的预览版。这些版本主要用于测试新特性，可能在日常操作中表现正常，也可能遇到莫名其妙的问题。你要找的应该是面向普通用户的稳定发布版，下载页面里通常会有清晰的标注。另外，如果你用的是 Linux 发行版，系统源里的版本可能不是最新的，但我个人认为这不重要。仓库里的版本已经经过发行版维护者的测试，和系统其他组件的兼容性更有保障，满足日常开发绰绰有余。
1.3 从哪里下载安装包最稳妥
安装 Git 最稳妥的方式是去它的官方站点下载，确保你拿到的是原始安装包，而不是从第三方下载站转存的版本。第三方站点的安装包经过二次打包后，存在被植入额外组件的风险，尤其是 Windows 用户，下载一个渠道不明的 exe 文件，装完以后发现浏览器被改了首页甚至多了全家桶的情况并不少见。
选择下载站点的时候，我的习惯是优先选离自己网络环境比较近的镜像。官方页面会提供多个下载入口，你可以直接找对应系统的安装包。下载完以后建议先看一眼文件大小，和页面上标注的体积对一下，如果差别太离谱，说明下载过程很可能出了问题，不要急着运行。安装包损坏的情况在网络波动时经常发生，下载完直接双击然后报错，很多人第一反应是系统问题，其实是包没下完整。
2. Windows 系统下的逐步骤安装过程
2.1 启动安装程序：从许可协议到安装路径
Windows 用户下载到的是一个.exe文件，双击以后会看到用户账户控制的弹窗，这是系统在询问你是否允许程序修改电脑设置，选择“是”即可进入安装向导。第一页是 GNU 通用公共许可证，做开发的人应该对这类协议不陌生，大意是你可以自由使用、修改和分发这个软件，但衍生作品也必须以同样的协议开源。直接拉到最下面，点击 Next。
接下来是安装路径选择。默认路径通常是C:\Program Files\Git，这个路径本身没有太大问题，但我建议你记住它。后续使用中你可能会需要手动找到git.exe的位置，很多新手在排查环境变量问题时就是卡在这一步。除非你有特殊需求，否则不要改到中文路径或带空格的路径之外的奇怪位置。把 Git 装在系统盘的好处是，重装系统前你不需要考虑备份工具本身，而且某些开发工具在查找依赖时会默认扫描系统盘的常见安装位置。
2.2 组件选择：哪些勾选值得保留
安装向导进入 Select Components 页面时，会出现一组勾选项。默认情况下，Git Bash Here 和 Git GUI Here 是选中的，这两个选项会在你的右键菜单里增加入口。Git Bash Here 是在当前文件夹打开一个 Git Bash 终端，Git GUI Here 则是打开图形界面。这两个功能建议保留，尤其是 Git Bash Here，进入一个目录后右键就能直接打开终端，比手动导航到该目录再启动终端快很多。
Additional icons 选项一般指桌面快捷方式，这个看个人喜好，需要的话就勾上。关联.git配置文件和.sh脚本文件的选项，默认不勾也行。我个人的做法是不让 Git 接管.sh文件，因为 Windows 下可能安装了其他脚本运行环境，关联以后会出现双击脚本不知道用谁打开的尴尬。Git LFS 是大文件存储组件，如果你以后要管理二进制资源、设计稿、数据集这一类大文件，建议装。Scalar 是一个性能增强工具，对大型仓库有帮助，但普通项目用不上，装不装都不影响核心功能。
2.3 默认编辑器、PATH 调整与 HTTPS 后端的选择
下一步是选择 Git 使用的默认编辑器。这个选项非常重要，因为 Git 在提交时如果没有通过-m参数指定提交信息，就会打开默认编辑器让你输入。默认选项是 Vim，而 Vim 对新手来说极不友好，打开以后完全不知道该怎么保存退出。我的建议是，如果电脑上已经安装了常见的代码编辑器，比如 VS Code、Notepad++、Sublime Text，就在这里选择对应的那一个；如果没装，直接选 Nano 也比 Vim 好上手得多。
随后是 PATH 环境的配置页面，这里有几个选项需要仔细看。推荐选项是 “Git from the command line and also from 3rd-party software”，意思是不光 Git Bash 里能用 Git，在 Windows 自带的 CMD、PowerShell 以及第三方终端里也能直接使用git命令。这个选项会帮 Git 自动调整系统 PATH。另一个选项 “Git from the command line only” 只把 Git 的命令行工具加入 PATH，第三方软件无法调用。最不方便的是 “Use Git and optional Unix tools from the Command Prompt”，它会把大量 Unix 工具也塞进 PATH，可能导致和 Windows 自带的命令冲突，我极少推荐选这项。
HTTPS 传输后端的选择页面上一般会提到 OpenSSL 和 Windows Secure Channel。OpenSSL 是 Git 自带的验证证书方式，兼容性更好，跨平台行为一致；Windows Secure Channel 则调用系统的证书存储机制，在企业内网使用代理或自签证书的场景下可能更合适。普通开发者保持默认选项，也就是 OpenSSL 即可。这个选择主要是影响访问代码托管平台时如何验证 SSL 证书，选错的表现是你明明网络正常，但git clone或git pull时老是报证书相关错误。
2.4 换行符转换、终端模拟器与 git pull 行为
Line Ending 也就是换行符配置，是 Windows 安装 Git 时最容易被忽略但后患无穷的选项。Windows 系统里的文本文件默认用回车加换行（CRLF）表示换行，而 Linux 和 macOS 系统用换行（LF）。Git 面对两种不同的换行符，需要决定如何处理。默认选项是 “Checkout Windows-style, commit Unix-style”，翻译过来就是：从仓库检出文件时转换成 CRLF，提交时再转回 LF。这个选项对 Windows 单一环境开发很友好，能避免很多编辑器兼容问题。
第二个选项 “Checkout as-is, commit as-is” 表示 Git 不做任何转换，仓库里是什么样，工作区就是什么样。这个选项适合团队里全是 Linux/macOS 用户、代码里有大量 shell 脚本的项目，因为脚本对换行符很敏感，CRLF 会导致脚本在 Linux 上执行时报错。第三个选项 “Checkout as-is, commit Unix-style” 是一个折中方案，检出时不管，但提交时统一转成 LF。我个人的倾向是：Windows 用户如果平时只写跨平台代码，保持默认第一项即可；如果你经常要和 Linux 环境打交道，可以在安装后再根据项目情况配置.gitattributes，通过提交一个规则文件让每个仓库有明确换行策略，比在每台机器上手动调选项更省心。
终端模拟器选择页会问你用 MinTTY 还是 Windows 默认控制台。MinTTY 是 Git for Windows 自带的终端，支持鼠标操作、复制粘贴更方便、颜色渲染更好看，缺点是中文输入在部分情况下会有奇奇怪怪的问题。Windows 默认控制台则和 CMD 外观一致，兼容性更强，但体验相对粗糙。我平时用 MinTTY，但如果发现某些终端插件或输入法不兼容，切回默认控制台也是一个解决办法。
接下来是git pull的默认行为。默认选项是 “Fast-forward or merge”，也就是能快进就快进，不能快进就自动创建一个合并提交。另外两个选项分别是默认使用 rebase 和只允许快进。这个设置只影响你在不带参数执行git pull时采用哪种更新策略，和git pull --rebase这种带参数的调用无关。团队协作时，建议把这个策略纳入团队统一约定，不要每个成员各用各的。
2.5 凭证管理器、文件系统缓存与符号链接实验选项
凭证管理器的选择会影响你以后和远程仓库交互时如何保存账号密码。默认选项是 Git Credential Manager，它会保存你的凭证，首次输入账号密码后，后续的git push、git pull就不再反复询问。如果你选择 None，意味着每次操作远程仓库都可能要重新输入用户名和密码，早期刚接触 Git 的人经常被这个体验劝退。开发环境里建议保留默认的凭证管理器，这和安全不冲突，因为凭证是加密存在你的用户目录下，而不是明文暴露在项目里。
接下来是 “Enable file system caching” 和 “Enable symbolic links” 两个选项。文件系统缓存是 Git 为了提升性能做的一个优化，它会缓存文件系统的一些元数据，在大型仓库上效果明显，默认勾选即可，我找不到任何理由在一个普通开发机上关闭它。符号链接选项默认不勾选，因为 Windows 上创建符号链接需要管理员权限，开启这个功能以后，某些操作可能会因为权限不够而失败。如果你不是在 Windows 上专门维护一个 Linux 风格的仓库，保持默认就行。
最后的实验选项一般指的是 pseudo console 支持，它是为了改善 Git Bash 中某些命令行程序的交互体验，比如让一些原本在旧终端中表现不佳的工具能正确响应键盘输入。作为普通用户，我的建议是全部保持默认。实验选项未必要勾选，除非你确实遇到了具体问题并且确认这个功能能解决它，否则没必要为求新而承担不确定的风险。
2.6 安装完成的验证操作
安装向导结束后，你的桌面或开始菜单里应该能看到 Git Bash、Git GUI 之类的入口。很多人装到这里就以为万事大吉，直接开始克隆代码，结果在终端里输入git --version，系统提示命令不存在。原因是安装时选择的 PATH 选项让 git 命令没有进入你当前使用的终端环境，或者当前终端是在安装之前打开的，没有刷新环境变量。
正确的验证方式是：新开一个 CMD 窗口或 PowerShell 窗口，输入git --version，如果显示出版本号，比如git version 2.x.x.windows.1，说明 Git 已经正确安装并进入了系统 PATH。如果是在 Git Bash 里输入这个命令，得到的版本格式会略有不同，但同样能看到版本信息。接下来还可以输入git --help检查帮助文档是否能正常显示，以及git config --list查看当前生效的配置内容。第一次执行这些命令时输出的信息可能不多，只要没有报错，安装就算成功了。
3. macOS 与 Linux 环境下的安装要点
3.1 macOS 的三种常见安装方式
macOS 上安装 Git 的途径比 Windows 要多，但每种方式的特点和使用场景不太一样。最简单粗暴的方式是从官方站点下载.dmg安装包，双击以后按照提示把 Git 拖入应用程序目录即可。这种方式的好处是版本可控、安装过程直观；缺点是后续要手动检查更新，而且你安装的 Git 和系统自带的工具之间可能产生版本差异。
第二种方式是通过系统自带的开发者命令行工具来安装。macOS 在终端里执行xcode-select --install，系统会弹出安装窗口，等待它装完以后，Git 也随之可用。这种方式对开发者来说其实很省心，因为很多编译工具也会一并安装，以后用 Homebrew 编译安装其他工具时不会再缺依赖。缺点是它安装的 Git 版本可能是系统自带的版本，更新节奏跟随系统更新，不一定能第一时间用上最新特性。
第三种方式是通过 Homebrew 这类包管理器安装，命令是brew install git。这种方式的优势是版本更新快，通过brew upgrade git就能轻松升级，而且安装路径清晰，不会和系统自带文件产生混乱。如果你已经在使用 Homebrew 管理开发环境，我强烈建议统一走这条路线，因为一套包管理器管理所有开发工具，维护成本最低。首次使用 Homebrew 时可能会提示你安装命令行工具作为依赖，这是正常流程，按提示走完即可。
3.2 Linux 发行版的包管理器安装
Linux 桌面发行版和服务器发行版的差异比较大，但绝大多数的 Git 安装方式都是通过包管理器一行命令完成。基于 Debian 或 Ubuntu 的系统使用sudo apt update && sudo apt install git -y，基于 Fedora 或 CentOS 的系统使用sudo dnf install git或sudo yum install git，基于 Arch 的系统使用sudo pacman -S git。这些命令在执行前最好先更新索引，否则可能出现找不到软件包或安装到旧版本的情况。
在 Linux 上装 Git 很少会遇到图形化选项，因为所有配置都可以在安装后通过命令行完成。有一点需特别提醒：在一些精简版服务器发行版上，系统默认软件源里的 Git 版本可能落后很多。遇到这种情况时，你可以先执行安装命令，版本够用就直接用；如果明确需要新版本，可以添加包含更新版本 Git 的软件源，也可以考虑使用源码编译，但后者对新手不太友好，编译过程依赖多个开发库，失败概率不低。日常开发和学习阶段，用系统源的版本完全没问题。
3.3 安装后的第一项检查
无论是 macOS 还是 Linux，装完以后都要在终端里执行git --version，确认输出结果是你预期中的版本。接着查看安装位置，执行which git，如果返回/usr/bin/git这样的路径，说明 Git 已经被系统识别。有时候电脑上同时存在多个 Git 版本，比如系统自带一个、Homebrew 装了一个，终端实际使用的是哪个，取决于 PATH 环境变量的顺序。这个顺序几乎不会影响你日常使用，但也别忽略它。
这里我想特别强调一件事：在 Unix 类系统上，Git 的默认分支名和 Windows 上的安装选项无关，它取决于本地配置。如果你在执行git init后发现默认分支名是master，而你的代码托管平台默认是main，可以在后续全局配置中修改，具体方法我会在下一章说明。第一项检查做完以后，有一个很常见的现象是提示缺少用户信息，这其实是正常的，因为 Git 安装时不会收集你的身份信息，需要在初始化配置阶段手动填写。
4. 安装完成后的初始化配置与检查
4.1 设置用户名和邮箱
Git 安装完成后并不会自动知道你是谁。每次提交代码时，Git 都会从配置中读取用户名和邮箱，并把它们写入提交记录。所以安装后的第一件事就是告诉 Git 你的身份，在命令行执行：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里有两个细节值得注意。第一，--global表示全局生效，也就是这台机器上的所有仓库都会用这个身份。如果你同时参与多个项目，不同项目需要不同身份，可以在项目仓库内不加--global单独设置。第二，邮箱不一定要和某个平台注册邮箱一致，但建议使用你注册代码托管平台时用的邮箱，这样你的提交记录能被正确关联到账号上。
设置完成后，可以用git config --global --list检查所有全局配置。看到user.name和user.email都正确显示，说明配置生效了。这一步看起来简单，但如果跳过，你第一次提交时要么收到报错提示，要么 Git 会用系统主机名拼一个不合理的默认身份，给以后维护提交历史造成麻烦。
4.2 生成 SSH 密钥并完成验证
很多人在安装完 Git 后会纠结一个问题：我用 HTTPS 方式克隆代码，还是用 SSH 方式？其实两者都可以，但对于长期开发者来说，配置 SSH 密钥更方便，因为配置好以后不用每次推送都输入账号密码。生成 SSH 密钥的命令是：
ssh-keygen -t ed25519 -C "你的邮箱"如果系统不支持 ed25519 算法（比较老的系统上偶尔会遇到），可以改用 RSA 算法：ssh-keygen -t rsa -b 4096 -C "你的邮箱"。执行后会出现提示，询问保存位置和密码短语。保存位置按回车用默认路径即可，密码短语可以不设置，直接再按一次回车，但如果你在意安全性，设置一个也不妨碍使用，只是每次建立连接时需要输入。
密钥生成后，默认会保存在用户主目录下的.ssh文件夹里，其中id_ed25519.pub是公钥，id_ed25519是私钥。公钥可以放心地添加到代码托管平台，私钥绝对不能泄露给别人。Windows 用户在 Git Bash 里执行这段命令后，可以用cat ~/.ssh/id_ed25519.pub查看公钥内容，复制到托管平台的 SSH Keys 设置里完成绑定。验证连接是否成功，需要执行ssh -T git@你的托管平台域名，如果返回欢迎信息，就说明密钥配置成功了。这一步即使暂时不做，也不影响 Git 的本地使用，但迟早会用到。
4.3 检查换行符与文本编码
在 Windows 上安装 Git 时，换行符配置已经决定了大部分行为，但安装完之后你还可以通过命令确认当前配置。执行git config --global core.autocrlf，如果返回true，说明当前是自动转换模式；如果返回空或false，说明没有开启自动转换。这个值是否合适，取决于你的团队约定和项目类型。如果你发现某些文件总是出现“whole file changed”的差异，极大概率就是换行符在捣乱。
另一个值得配置的是提交信息文本编辑器。前面安装步骤里选了默认编辑器，但如果你想在安装后修改，可以用git config --global core.editor "code --wait"，把默认编辑器换成 VS Code 之类的现代编辑器。注意这里的写法要符合不同操作系统的调用方式，Windows 下 VS Code 的命令是code --wait，macOS 下同样的命令。这个配置在你提交时需要写多行提交信息时会非常有用。文本编码方面，Windows 上如果之前已经在 Git Bash 里设置了中文路径和中文文件名相关配置，安装完成后通常不需要额外操作，但我个人会在全局配置里设置core.quotepath false，这样中文文件名在git status输出中不会被转义成一串反斜杠数字。
5. 安装时最容易踩的坑与排查思路
5.1 下载页打不开或安装包损坏
官方下载页有时候响应比较慢，尤其在某些网络环境下，浏览器可能一直转圈。解决办法很简单：换一个镜像站点下载，或者稍后再试。有时候不是网络问题，而是浏览器把下载文件的扩展名改了，下载完发现是一个没有类型的文件，这种也可以先重命名为.exe或.dmg再尝试运行。如果安装包双击后提示“不是有效的 Win32 应用程序”，先别怀疑系统，检查一下下载文件的大小，明显偏小就删掉重新下载。
安装包损坏的原因通常有两种：下载过程中断，或者是浏览器插件拦截了部分内容。使用下载工具或者干脆换一个浏览器下载，问题基本能解决。还需要提醒的是，如果你下载的安装包被系统安全组件拦截，系统会弹出一个提示，这时候你要确认这个安装包确实来自官方来源，然后选择仍然运行。如果你是从非官方下载站拿来的，被拦截反而是一个善意提醒。
5.2 安装后命令行提示“git 不是内部或外部命令”
这个问题最常见的根源，是安装时选择的 PATH 选项不对，或者安装前已经打开的命令行窗口没有刷新环境变量。先说处理方式：关掉所有已经打开的终端窗口，重新开一个新的，再输入git --version。如果仍然提示命令不存在，打开系统设置里的环境变量编辑界面，检查 PATH 中是否包含 Git 的安装路径，比如C:\Program Files\Git\cmd。没有的话就手动添加，然后重新打开终端。
如果是 Linux 或 macOS 下出现类似问题，比如提示command not found，先检查是否真的安装了 Git，可以执行/usr/bin/git --version或/usr/local/bin/git --version看看到底有没有。如果文件存在但命令找不到，说明安装目录不在 PATH 里，手动把对应目录加入~/.bashrc或~/.zshrc即可。这一步对新手来说稍微绕一点，但原理不复杂：系统只是在固定的几个目录里找可执行文件而已。
5.3 换行符警告 CRLF/LF 问题
很多 Windows 用户在第一次git add或git commit时看到一句话：warning: LF will be replaced by CRLF或warning: CRLF will be replaced by LF。第一次看到很容易慌，但这是 Git 在提示你它即将进行换行符转换，并不是错误。这个警告实际的含义是：你工作区里的文件换行符和 Git 仓库里的规范不一致，Git 正在按照你安装时选择的换行符策略进行归一化处理。
如果你完全不想看到这个警告，而且团队所有人都使用同一类系统，可以在全局配置里把core.autocrlf设为false。如果你的项目统一要求 LF，可以在项目根目录添加一个.gitattributes文件，明确指定文本文件的换行符规则，这样团队里任何系统都会按规则执行，比每个人手动改配置靠谱得多。这条经验是我踩过几次坑之后总结出来的，依赖个人配置的换行策略，迟早会出现某个人提交了一堆无关的换行符改动。
5.4 右键菜单里找不到 Git Bash Here
安装时勾选了 Windows Explorer integration，但装完以后发现右键菜单里没有 Git Bash Here。这种情况通常有两个原因。第一，右键菜单选项在二级菜单中，有些系统或软件会把它折叠到“显示更多选项”里，需要多点一次。第二，安装完成后没有重启资源管理器或重新登录系统，菜单不会立即刷新。
处理方式是，在任务管理器里找到“Windows 资源管理器”，右键选择重新启动，或者直接重启电脑。如果重新启动后还没有，检查一下安装时是否勾选了相关组件，没有勾选的话只能重新运行安装包，在修改界面勾选补装。这类小问题原理上不复杂，但确实会在安装后立刻影响使用体验，值得提前知道。
5.5 Git Bash 中文乱码
Windows 下用 Git Bash 查看中文文件名或中文提交信息时，偶尔会出现乱码。这种情况大多和终端的编码设置有关。Git Bash 默认的编码行为和 Windows 控制台有时不一致，当你仓库里的文件名或日志包含中文时，显示就会变得不可理解。一个简单有效的办法是在 Git Bash 窗口标题栏右键，进入选项设置，将文本编码调整为 UTF-8，并选择中文字体。
除了终端层面，Git 自身也有一个关键配置：git config --global core.quotepath false。没有这个配置时，Git 会把中文路径转义成类似\345\274\200\345\217\221的八进制序列，看起来就像乱码。设置了这个配置以后，中文文件名在git status输出中才会正常显示。这个配置本身非常安全，只影响显示方式，不影响实际存储。
5.6 安装后 HTTPS 操作报证书错误
安装时如果选择了 OpenSSL 作为 HTTPS 后端，在某些公司网络环境或代理环境下，可能会遇到SSL certificate problem: unable to get local issuer certificate之类的报错。这个问题通常不是 Git 安装错误，而是系统没有安装对应的根证书，或者你的环境里存在代理证书拦截。先不要急着关闭 SSL 验证，那是一个治标不治本的办法，会让所有 HTTPS 传输失去安全保护。
建议的顺序是：先检查系统时间和日期是否正确，很多证书错误其实是电脑时间不对导致的；然后确认你的网络环境中是否存在代理拦截，如果公司有统一的根证书，安装到操作系统受信任的根证书列表里；最后才考虑更新 Git 或在 Git 全局配置中调整证书指向。普通家庭网络环境下遇到证书错误的情况很少，一旦遇到，多半是时间问题。
6. 写在最后：几点个人安装习惯
按照这套流程装下来，正常情况下你的 Git 已经可以稳定使用了。最后分享几个我个人的安装习惯，可能对你有参考价值。第一，Windows 上我总是选择默认的 PATH 配置和默认的换行符转换，除非团队有明确的跨平台要求，否则不为“以后可能用到”的选项提前做变更。第二，安装完成后我会立刻配置用户名和邮箱，并生成 SSH 密钥，这一步虽然不影响本地初始化仓库，但避免了下一次克隆远程项目时被认证问题绊住。
第三，我习惯在安装后主动打开一个全新的终端，跑一遍git version、git config --list、ssh -T三个命令，全部通过才算真正装完。这几个命令看着简单，但能一次性暴露安装路径、身份配置、密钥连接三类问题。第四，如果发现某些选项当时选得不够合适，不需要重新安装，直接修改环境变量或用git config命令调整就行，安装向导里的选项绝大多数都不是不可逆的。
Git 本身就是一个越用越顺手的工具，安装只是第一步。真正值钱的是安装完之后，你能顺利跑通提交、分支、合并、推送这一条完整链路。如果看这篇文章的你把环境顺利搭起来了，建议立刻创建一个仓库，提交一次代码，体验一下整个流程，遇到问题再回头对照本文的排查思路，基本上都能找到原因。
