每次帮新同事配开发环境，我都会发现一个规律：越是觉得“装软件这种小事不用教”的人，越容易在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 git，Red 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 LFS（Large 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 Git's 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的忠实用户，因为它的Ctrl+V粘贴、鼠标选中即复制、滚动缓冲这几个特性都做得比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）一致的邮箱。这样平台上的提交记录就能正确关联到你的账号头像和贡献图。很多新手在这步嫌麻烦直接跳过，结果提交记录里显示的全是一串乱码或者user@DESKTOP-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配置会覆盖global，global会覆盖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 git@gitee.com如果看到Hi 用户名! You've 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 git@gitee.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 -> Git，VS Code在设置 -> git.path。这里有个2026年值得注意的点：新版Git for Windows默认同时安装了32位和64位版本的情况已经很少见，但如果你之前手动覆盖过PATH，IDE里指向的版本可能不是你实际安装的版本。建议在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安装这件事，真正的分水岭不是“装没装上”，而是“装完之后你懂不懂每个配置在替你做什么”。希望这篇把安装阶段和首次配置阶段讲透之后，你能少走几次弯路。
