不用怀疑，Git 这东西只要你碰代码，早晚绕不开。尤其是 Windows 用户，从“下载安装”到“能顺手敲出日常命令”，中间其实隔着好几个容易踩坑的坎，比如环境变量没生效、换行符告警、SSH 认证失败、还有那个经典的fatal: not a git repository。这篇东西就是写给在 Windows 上折腾 Git 的朋友，从零开始装，讲清楚每一步为什么这么做，最后带你走一遍日常最常用的命令流程，再附上我实际踩过的一些坑和排查方法。无论你是刚接触版本控制的新手，还是装了好几次但总觉得哪里没配对的半熟手，这篇文章都值得你花几分钟从头到尾过一遍。
1. 安装前的准备与版本选择
1.1 为什么要用 Git for Windows 而不是其他版本
很多人第一次接触 Git，会被各种名词绕晕，什么 Git for Windows、Git Bash、MinGW、MSYS2、GUI 客户端……其实你只需要记住一个结论：在 Windows 上装 Git，认准官方发布的 Git for Windows 就够了。它不是一个简单的命令行工具移植版，而是一整套完整的环境，自带 Git Bash（一个模拟 Linux 终端的 shell 环境）、Git GUI（图形界面），以及最核心的 Git 命令行工具本身。
为什么不推荐只装一个裸的 Git 命令行？因为 Windows 原生的 CMD 和 PowerShell 对很多 Git 操作的支持并不友好，尤其是那些依赖 shell 脚本的功能，比如某些钩子（Hook）脚本、复杂的路径展开、通配符处理等。Git for Windows 自带的 Git Bash 基于 MSYS2 环境，它给你一个类 Unix 的终端体验，让那些在 Linux/macOS 上写好的脚本能直接在 Windows 上跑，这个价值远大于“只是一个 Git”。我自己刚在 Windows 上写脚本的时候也踩过类似的坑——在 CMD 里执行一个包含通配符的 Git 命令，结果路径解析错了，换了 Git Bash 之后就再没出现过这个问题。
另一个重点是版本选择。官方提供 32 位和 64 位两个版本，现在的主流电脑基本都是 64 位系统，闭着眼睛选 64 位就好。但有一个细节很多人没注意：官方还区分“完整安装包”和“便携版”。便携版不需要安装，解压就能用，适合 U 盘里放一个应急用；但日常开发我不推荐便携版，因为它少了右键菜单集成和 Windows 凭据管理器的自动配置，这些恰恰是新手的痛点。老老实实用完整安装包。
1.2 从官网下载的正确姿势
下载这事看着简单，其实也有讲究。直接搜索“git 下载”出来的结果里，有一堆第三方下载站，挂着各种“高速版”“增强版”。我建议只看官方源，地址是git-scm.com，进去之后页面会自动识别你的操作系统，给你推荐下载链接。如果你打开速度慢，可以去国内的开源镜像站下载，但下载完必须校验一下文件签名或哈希值，这是防止下载到被篡改文件的基本意识。
这里有一个很实用的经验：官网的下载页会自动检测系统版本，但偶尔会误判。如果你在 64 位系统上不小心下载了 32 位版本，不是不能用，但以后装一些需要调用 Git 原生 DLL 的工具（比如某些 IDE 插件）时，可能会遇到架构不匹配的奇怪问题。所以下载之前，顺手按Win + Pause看一眼系统类型，确认是 64 位还是 32 位，这个动作十秒钟都花不到，能省掉后面一堆排查时间。
另外，官网还提供“历史版本”的入口，在下载页面底部。为什么要提这个？因为有些老项目的构建脚本依赖特定版本的 Git 行为，升级到最新版可能会触发一些兼容性问题。比如我见过一个项目，用的脚本依赖 Git 2.23 当时的一个返回码行为，升级到 2.40 之后构建流程就崩了。虽然这种情况不常见，但知道怎么切版本，遇到这类项目时能救命。
2. 安装过程的每一处配置到底在选什么
2.1 安装向导的关键选项逐个拆解
Git for Windows 的安装向导是英文界面，很多新手在这里就被劝退了。其实只要搞懂几个关键选项的意思，整个过程比装普通软件更简单，下面我按实际点击顺序给你拆一遍。
首先是选择组件（Select Components）。默认选项里包含“Git Bash Here”和“Git GUI Here”的右键菜单集成，这两个务必保留。装完之后你在文件夹空白处点右键，能看到“Open Git Bash here”，直接就在当前目录打开终端，这个便利性在平时使用时太高频了。还有一个“Add a Git Bash Profile to Windows Terminal”选项，如果你用 Windows Terminal（Win11 自带或 Win10 商店安装），建议勾上，这样以后可以直接在 Windows Terminal 里切换 Git Bash 环境，体验比单独的窗口好很多。
然后是“默认编辑器”（Default editor）的选择。老版本安装包默认是 Vim，很多人进去之后不会退出，卡死在那个界面，最后直接把命令行窗口关了。新版安装包默认改成了 Vim 但给了下拉选项，你可以选 Nano，或者选自己装的 VS Code / Notepad++。强烈建议选 VS Code，因为 Git 在提交时会打开编辑器让你写提交信息，VS Code 对新手友好太多，而且 VS Code 本身就内置了强大的 Git 图形支持，至少可以解除 Vim 的复杂性造成的干扰。
接下来是“调整 PATH 环境变量”（Adjusting your PATH environment）这个选项，也是我见过翻车最多的地方。它有三个单选：
Use Git from Git Bash only：只在 Git Bash 里能用 Git，CMD 里敲git找不到命令。Git from the command line and also from 3rd-party software（推荐默认）：把 Git 加到系统 PATH，CMD、PowerShell、IDE 里都能直接用。Use Git and optional Unix tools from the Command Prompt：不仅把 Git 加进去，还把一堆 Unix 工具（比如find、sort）覆盖到 Windows 系统命令里。
我明确说：选第二个，不要选第三个。选第三个的坑在于，它会把 Unix 版本的find.exe这些工具丢进系统 PATH，覆盖掉 Windows 自己的find.exe。有些脚本会调用系统的find命令，结果执行的是 Unix 版本，行为完全变了，排查起来特别隐蔽。我当年就吃过这个亏，一个批处理脚本莫名其妙行为异常，最后发现是 PATH 被改过了。选第二个，CMD 和 IDE 都能用git，足够了。
2.2 换行符转换、凭据管理器与额外选项的坑
安装向导后面几步还有几个容易忽略但实际上非常影响日常体验的选项。
“换行符转换方式”（Line Ending Conversions）有三个选项：第一个是“按检出方式转换”（Checkout Windows-style, commit Unix-style），第二个是“按原样检出”（Checkout as-is, commit as-is），第三个是“检出时转成 Unix 格式，提交时也保持 Unix 格式”。默认是第一个。这个问题的根源在于 Windows 用CRLF换行，Linux/macOS 用LF换行，Git 需要处理这个差异。如果你和团队都在 Windows 上，用默认的第一项问题不大；如果项目里有跨平台协作，或者你发现 Git 总提示“file has both CRLF and LF”这类告警，建议项目根目录放一个.gitattributes文件来统一规则，比在每台机器上改全局配置要可靠得多。我第一次参与开源项目给 Windows 提交代码时，就是因为没有配.gitattributes，后来无数次的告警才让我明白了这个道理。
“凭据管理器”（Credential Manager）默认是Git Credential Manager，这个选项很关键。它解决了 HTTPS 方式克隆仓库时每次都要输入账号密码的痛点。安装完成后，第一次通过 HTTPS 访问远程仓库时，Windows 会弹出一个登录框让你输账号密码，输一次之后凭据就被安全存储在 Windows 凭据管理器里了，后续操作自动使用。如果你发现哪一天 Git 一直提示认证失败，记得去“控制面板 → 用户账户 → 凭据管理器 → Windows 凭据”里找到git:https://xxx的条目删掉，重新认证一次。这个问题遇到的人非常多。
“额外选项”（Configuring extra options）有两个：一个是启用文件系统缓存（Enable file system caching），默认勾选，建议保留。另一个是启用符号链接支持（Enable symbolic links），默认不勾选，建议保持默认。Windows 上启用符号链接需要管理员权限和开发者模式，而且很多 Windows 文件系统工具（比如资源管理器、压缩软件）对符号链接的支持并不好。除非你的项目明确需要跨平台的符号链接，否则别碰这个选项，不然项目里出现几个莫名其妙的符号链接，删都删不干净。
装完之后，把安装向导最后一页的两个启动选项（查看发行说明、启动 Git Bash）关掉，点 Finish 就行。然后重新打开一个终端（如果是已经开着的 CMD，务必关掉重开，因为环境变量 PATH 改了之后需要新进程才能读到），输入git --version，看到版本号输出，说明安装成功了。
3. 安装后的初始化配置与免密设置
3.1 全局配置 user.name 和 user.email
安装成功之后，第一件事不是急着克隆仓库，而是先初始化你的身份信息。这步不做好，后面每次提交都会报错或者生成一串错误的提交者信息。打开 Git Bash，执行：
git config --global user.name "你的名字" git config --global user.email "你的邮箱"这里有一个很多人没想明白的点：user.name 和 user.email 不一定要填 GitHub 的用户名和注册邮箱。Git 记录的是你提交时的身份，这个身份会永久留在提交历史里。很多人在公司项目里习惯用公司邮箱，在个人项目里用个人邮箱，这个没问题，但要注意：如果你是给 GitHub 上的开源项目提交代码，提交者的邮箱最好和你的 GitHub 账号邮箱一致，否则 GitHub 不会把你的提交关联到你的账号上，你的贡献图会是空的，别人看到你的提交也点不进你的主页。这个细节我自己也踩过坑，因为注册 GitHub 时用了临时邮箱，后来换主邮箱导致所有提交都没关联上。
验证配置是否生效，执行：
git config --global --list这个命令会列出所有全局配置项。如果发现配置错了，可以随时用上面的命令重新配置。如果你只想临时给某个仓库用不同的身份，在这个仓库目录下执行不带--global的配置命令即可，仓库级别的配置优先级高于全局配置。
还有一个细节值得说一下：Git 在 2.28 版本之后引入了一个init.defaultBranch配置项。老版本默认分支名是master，新版本安装包在初始化仓库时，默认分支名取决于你的配置。建议显式设置为main（更通用）：
git config --global init.defaultBranch main为什么要提这个？因为现在很多代码托管平台（GitHub、GitLab）新建仓库时默认分支就是main，你本地初始化仓库时如果还是master，推送前还得手动改分支名，多一步操作。提前配好，省心。
3.2 生成 SSH 密钥并配置到代码托管平台
配置完身份信息之后，接下来是 SSH 密钥。为什么用 SSH？因为 GitHub、Gitee 这些平台早就开始限制 HTTPS 方式拉代码的频率了，而且早晚会淘汰密码认证。SSH 用密钥对来认证，不仅更安全——私钥留在本地，公钥放到平台——还能实现免密操作：一次配置，之后所有拉取、推送都不用输密码。
生成密钥的命令：
ssh-keygen -t ed25519 -C "你的邮箱"这里用ed25519而不是经典的rsa，是因为 ed25519 密钥更短、生成更快、安全性更高，而且现在主流平台都支持。如果你用的 Git 版本比较老（2.23 之前的版本），可能对 ed25519 支持不完全，那可以用ssh-keygen -t rsa -b 4096 -C "你的邮箱"代替。不过既然是新装的 Git，直接用 ed25519 就好。
执行之后，一路回车即可（除非你想给私钥加密码，新手建议不加或加一个简单的，不然每次操作都要输密码，很容易把热情磨灭了）。生成的文件默认在C:\Users\你的用户名\.ssh\目录下，其中id_ed25519是私钥，千万不能泄露给任何人；id_ed25519.pub是公钥，可以放心给平台。
然后查看公钥内容：
cat ~/.ssh/id_ed25519.pub把输出的那一整行复制下来，登录 GitHub → Settings → SSH and GPG keys → New SSH key，粘贴保存。Gitee 的用户去“设置 → SSH 公钥”里粘贴保存。添加完成后，在 Git Bash 里验证：
ssh -T git@github.com如果你是 GitHub 用户，会看到类似Hi 用户名! You've successfully authenticated, but GitHub does not provide shell access.的输出。看到这行字，说明 SSH 通了，公钥配置成功，从此以后免密操作。如果是 Gitee，命令换成ssh -T git@gitee.com，会看到“成功验证”的字样。
这里面有一个我反复遇到过的问题：SSH 密钥生成之后无法认证。排查步骤也很简单：第一步，确认你的公钥已经粘贴到平台；第二步，执行ssh -T命令时如果报Permission denied (publickey)，说明 Git 没找到你的私钥，试一下ssh-add ~/.ssh/id_ed25519把密钥加到 ssh-agent 里，然后再试；第三步，如果还是不行，检查一下~/.ssh/config文件是否存在内容错误，比如指定了错误的密钥路径。这个错误在网络热词里占了很大的比例（ssh认证失败 git），可见它坑了多少人。
3.3 HTTP 代理与 Windows 凭据管理器的关系
有些网络环境需要走代理才能访问 GitHub 等外国网站。这里不讨论代理工具的选型，只说 Git 层面的配置方法。
Git 支持为 HTTP/HTTPS 协议单独配置代理：
git config --global http.proxy http://127.0.0.1:端口号 git config --global https.proxy http://127.0.0.1:端口号这个配置的意思是：所有通过 HTTP/HTTPS 协议进行的 Git 操作（包括克隆、拉取、推送）都会走这个代理地址。如果你的网络环境不需要代理，切记不要配置这个，因为一旦配置了，Git 会一直尝试连接代理端口，连接失败就报各种超时错误，非常难排查。
我遇到过最头疼的一种情况是：用户配置了代理，后来换了网络环境，代理工具忘了开，Git 操作直接卡死。排查了半天，最后发现是http.proxy这个配置项在作怪。所以这里记住两个常用命令：
# 查看当前代理配置 git config --global --get http.proxy # 删除代理配置 git config --global --unset http.proxy另外补充一点：如果你使用 GitHub Desktop 或其他 GUI 客户端，它们可能会自动帮你设置凭据和代理配置，所以当你发现命令行 Git 行为异常时，先检查一下全局配置是不是被什么工具改过了。git config --global --list配合git config --global --list --show-origin（能显示配置来源文件路径），排查起来效率会高很多。
4. Git 日常使用的核心命令工作流
4.1 初始化仓库与克隆远程仓库
配置好身份和 SSH 之后，就可以正式开始使用了。日常使用分两种情况：从零开始一个新项目，或者拿到一个已有项目的远程仓库地址。
从零开始，在项目文件夹里打开 Git Bash，执行：
git init这个命令会在当前目录下创建一个隐藏的.git文件夹，这个文件夹就是 Git 的“数据库”，所有版本历史、分支信息、配置都存这里。注意：.git 文件夹千万不要手动去改里面的文件，除非你明确知道自己在干什么。我见过有人因为好奇去翻了 .git 里面的 config 文件，改坏了路径，整个仓库都废了。
如果你有远程仓库地址，就不需要git init，直接克隆：
git clone git@github.com:用户名/仓库名.git这里用 SSH 地址而不是 HTTPS 地址，因为前面我们已经配好了 SSH 密钥，用 SSH 地址才能免密。如果你拿到的是 HTTPS 地址，也可以直接用，但每次操作都会要求输入账号密码（除非配置了凭据管理器且已登录过）。
克隆完成后，进入项目目录，执行git status看看当前状态。这个命令是平时敲得最多的命令之一，它会告诉你：当前在哪个分支、文件是否有改动、有没有未跟踪的新文件等。养成一个习惯：每次操作前后都看一眼git status，能避免很多失误。
4.2 分支管理与合并的正确姿势
分支是 Git 最强大的特性，也是新手最难理解的概念之一。一句话解释：分支就是一个独立的开发线，你在分支上做的提交不会影响主分支，等开发完了再把改动合并回去。
查看当前分支：
git branch新建一个分支并切换过去：
git checkout -b feature/xxx或者在新版 Git 中更推荐：
git switch -c feature/xxxgit switch是 Git 2.23 版本引入的新命令，语义更清晰，专门用来切换分支；git checkout身兼多职（切分支、恢复文件、撤销改动），容易让人困惑。既然是新装的 Git 2.40+，建议直接养成用git switch的习惯。
在分支上做了一些修改以后，切回主分支，合并开发分支：
git switch main git merge feature/xxx合并操作会把你所在分支的改动合并到当前分支。正常情况下合并是自动完成的，但如果两个分支都改了同一个文件的同一行，Git 无法自动判断该保留哪个，就会产生冲突（conflict）。冲突发生时，Git 会在冲突文件中用标记把两边内容都标出来，你需要手动打开文件，决定保留哪部分，然后保存，再执行：
git add 冲突文件 git commit关于分支合并，网络热词里经常出现，可见这是高频操作。我给你的建议是：小步提交，勤切分支，遇到冲突别慌。冲突不是错误，是 Git 在保护你的代码不被静默覆盖。它把选择权交给你，是好事不是坏事。
4.3 日常操作的黄金组合：add、commit、push、pull
每天最频繁的四个操作就是add、commit、push、pull。它们构成了一个最基础的工作循环。
第一步，把改动添加到暂存区：
git add .git add .表示把所有改动（包括新文件和修改过的文件）都加到暂存区，但不包括删除操作，删除文件需要用git add -A或者git rm 文件名。一个小细节：git add .是当前目录及子目录，git add -A是整个仓库，在仓库根目录执行效果一样。如果你在子目录里执行git add .，只会暂存子目录及以下的改动，这点容易搞混。
第二步，提交到本地仓库：
git commit -m "提交信息"提交信息建议遵循一定的规范，比如feat: 新增用户登录功能、fix: 修复列表页白屏问题。好的提交信息是给未来的自己看的，别写“修改了一些东西”这种没用的话。如果你没加-m，Git 会打开你配置的编辑器让你填写提交信息，这就是为什么之前建议你选 VS Code 而不是 Vim 的原因。
第三步，把本地提交推送到远程：
git push如果是第一次推送新分支，Git 会提示你没有上游分支，需要指定：
git push -u origin 分支名-u参数的意思是 “设置上游分支”，设置一次之后，以后直接git push就行，不用每次都写全。
第四步，拉取远程更新：
git pull推荐一个习惯：在开始一天的工作前，先git pull一次，把远端其他人提交的代码同步到本地，减少后面合并冲突的概率。同样，在git push之前如果有远端更新，Git 会拒绝推送（non-fast-forward），要求你先git pull合并，这是 Git 的默认保护机制。处理方式很简单：先git pull，如果有冲突就解决，没有冲突 Git 会自动完成合并，然后重新git push即可。
这四个命令串起来的日常循环就是：改代码 →git add→git commit→（有冲突先处理）→git push→ 下次开工先git pull。只要这个循环跑顺了，你再也不会回退到“代码靠复制粘贴备份”的原始时代。
4.4 撤销与回滚：给冲动操作留一条后路
Git 的好处之一就是操作可回退，但回退的方式有好几种，很多人记不住，这里给你一张速查表。
| 场景 | 命令 | 说明 |
|---|---|---|
| 改乱了文件，想丢弃工作区的改动 | git checkout -- 文件名 | 用暂存区/HEAD 的版本覆盖工作区文件 |
| 加了错误文件到暂存区，想取消暂存 | git reset HEAD 文件名 | 从暂存区移除但保留工作区改动 |
| 刚提交完，发现提交信息写错了 | git commit --amend -m "新信息" | 修改最近一次提交的信息 |
| 想撤销某个已提交的改动（但保留提交记录） | git revert 提交ID | 生成一个反向提交，用于已经推送到远程的情况 |
| 想直接丢弃最近若干次提交 | git reset --hard HEAD~2 | 表头是“危险操作”，之后提交的记录会蒸发。 |
| 想查看所有历史操作找回丢失的提交 | git reflog | 显示所有 HEAD 移动记录，即使 reset 也能找回 |
特别注意git reset --hard：这个命令会丢弃工作区所有未提交的改动，而且这些改动无法恢复。我在网上看到过太多教程教人“搞乱了就reset --hard”，但实际上这种操作带来的后果是灾难性的。如果确实犯了错误，先运行git stash（临时保存当前改动）或者git reflog（查看还能不能找回），永远比一句“我重置了”更稳妥。我自己用 Git 这么多年，git reset --hard一共只敲过两次，每一次都是彻骨之痛换来的教训。
另外提一下git stash，这个命令被严重低估了。它的作用是：把当前未提交的改动暂存起来，把工作区恢复干净，然后再用git stash pop恢复之前暂存的改动。典型场景：你正在一个分支上写了一半代码，老板让你紧急切到另一个分支修个 bug，这时候你不想把写一半的代码带过去，git stash完美解决。
5. 高频报错排查与避坑实录
5.1 fatal: not a git repository
这个报错的频率之高，几乎每个 Git 新手都会遇到。完整报错是：
fatal: not a git repository (or any of the parent directories): .git原因非常直白：当前所在的目录不是一个 Git 仓库。要么是你在一个没有执行过git init和git clone的普通文件夹里使用 Git 命令，要么是你用 Git Bash 打开时路径跳到了错误的位置。
排查方式：先执行pwd（Git Bash 里）或cd（CMD 里）看当前路径，再执行ls -a或dir /a看有没有.git文件夹。如果你原本应该在一个仓库里，但执行命令时不在仓库根目录，也会报这个错。解决办法就是切回仓库根目录，或者确定自己要在哪个文件夹建仓库，执行git init。
还有一个隐蔽的情况：你在仓库的子目录里运行 Git 命令时，Git 会向上查找.git文件夹，所以正常情况子目录里也能用 Git 命令。但如果你的仓库文件夹本身被移动过位置，或者.git文件夹被误删了（有些人清理磁盘时把它当垃圾删了），就会报这个错。所以：不要手动删 .git 文件夹，除非你确定要放弃这个仓库的全部历史。
5.2 Windows 下 Git Bash 无法使用 git 命令
有时候明明安装成功了，但在 Git Bash 里却提示git: command not found。这种情况一般是 PATH 环境变量没有正确生效。安装 Git 时如果选了第一项（只在 Git Bash 里使用 Git），那么 CMD 里用不了git是正常的，但如果 Git Bash 里也用不了，就要检查安装时是否真的勾选了相关组件。
排查步骤：先关闭所有终端窗口，重新开一个 Git Bash，输入which git。正常情况会输出 Git 安装路径下的cmd/git.exe。如果提示找不到，你手动去安装目录看看，比如C:\Program Files\Git\cmd\git.exe是否存在。如果文件存在但 Git Bash 找不到，那你可能用的是 Windows 自带的终端而不是 Git Bash，或者 PATH 配置被某些软件干扰了。
另外推荐一个小习惯：装完 Git 之后重启一次电脑。这不只是为了玄学，而是因为安装程序改了系统环境变量 PATH，而 Windows 的系统环境变量在旧的 Terminal 进程里不会自动刷新，重启最省心。我见过太多人装完了在旧 CMD 里敲命令报错，然后怀疑安装失败、反复重装。
5.3 明文存储密码警告与旧仓库在 Git 8 的注意点
新版 Git 在 HTTPS 克隆时会显示一条警告：
warning: 检测到您正在使用明文存储密码的方式...这个警告的本意是提醒你：Git 配置了credential.helper用明文保存密码的方式存储，而这种方式在网络安全意识上是不推荐的。现代版 Git 默认用的是manager（Windows 凭据管理器），一般是安全的；但如果你之前手动配置过credential.helper store，就可能会收到这个警告，因为store模式是把密码明文写在~/.git-credentials文件里的。
解决办法：把凭据管理器切回 Windows 凭据管理器：
git config --global credential.helper manager如果你发现某天 Git 操作总是提示认证失败，大概率是凭据管理器里的条目过期或者被改了。去 Windows 凭据管理器里找到对应的git:https://...条目删掉，重新操作一次就会弹出登录框让你重新输入，不会丢失任何代码数据。
5.4 Git LFS 安装与使用注意
如果你的项目里有大文件（比如设计稿、模型文件、视频素材），普通 Git 仓库会很快变得臃肿，克隆速度直线下降。Git LFS（Large File Storage）就是专门解决这个问题的。它的原理是：把大文件替换成轻量级的指针文件存进 Git 仓库，真正的文件内容存到 LFS 服务器上。
安装 LFS 之前先确认是否已集成。新版 Git for Windows 安装包已经自带 LFS 了，如果用的是老版本，可以单独执行：
git lfs install然后在仓库里跟踪指定类型的大文件：
git lfs track "*.psd" git lfs track "*.zip"执行完git lfs track之后，仓库根目录会生成一个.gitattributes文件，Git 会通过它识别哪些路径需要走 LFS。这个文件必须提交到仓库里，否则其他协作者拉代码时不知道这些文件是 LFS 管理的，会出现各种奇怪的问题。我曾经见过团队成员没有提交.gitattributes，导致同一个文件在不同人那里表现不一致，排查了很久。
关于 LFS 有一条很重要的经验：在已经用普通 Git 提交过大文件之后，再启用 LFS 并不能自动修复历史。已经提交到 Git 历史里的大文件依然存在于历史记录中，仓库仍然臃肿。要真正瘦身，你需要通过git lfs migrate重写历史，这是一个高级操作，建议在确实需要时先去查阅官方文档，不要在生产仓库上贸然试验。
5.5 常用问题速查表
| 报错信息 | 可能原因 | 解决方案 |
|---|---|---|
fatal: not a git repository | 当前目录不是 Git 仓库 | cd到仓库根目录，或执行git init |
Permission denied (publickey) | SSH 私钥未被识别 | 确认私钥路径，ssh-add ~/.ssh/id_ed25519 |
Please make sure you have the correct access rights | SSH 公钥未配置到平台 | 检查平台 SSH 公钥列表是否已添加 |
failed to push some refs to | 远程有本地没有的提交 | 先git pull再git push |
warning: LF will be replaced by CRLF | 换行符规则配置不一致 | 配置.gitattributes统一换行符 |
terminal is not fully functional | Git Bash 终端类型不兼容 | 在 Git Bash 中设置export TERM=xterm |
unable to access 'https://...': SSL certificate problem | HTTP SSL 证书问题 | 执行git config --global http.sslverify false临时绕过 |
error: src refspec main does not match any | 当前分支没有提交内容 | 先git add提交一次，或确认分支名正确 |
5.6 Windows 上 Git 命令无法写入中文信息的解决
这是一个在国内环境里非常常见但教程极少提及的问题：在 Git Bash 里输入中文提交信息，提交之后在远程仓库看到的是乱码或者空的提交说明，甚至在某些 IDE 里显示成UTF-8乱码。问题根源大概率是 Git 的编码配置和终端编码不一致。
git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8另外在 Git Bash 窗口标题栏右键 → Options → Text，把字符集改为 UTF-8，这个设置能保证终端输入和显示都是 UTF-8 编码。改完设置之后重启 Git Bash 再试。
如果你使用 Windows 系统自带的 CMD 窗口操作 Git，中文问题会更明显。建议直接放弃 CMD 改用 Git Bash 或 Windows Terminal，能少掉一堆编码带来的烦恼。
6. 最后的几点实用建议
说了这么多，最后分享几个我实际用下来最值得养成的习惯。这些不是“必须”，但如果你能养成，后续踩坑的概率会直线下降。
第一，提交信息写清楚，小步提交。我见过太多人习惯性地把所有改动攒到一起然后一次性提交，遇到问题想回滚时发现无从下手。改成“改完一个功能点、提交一次”，回滚时精确打击，这个习惯花不了多少时间，收益巨大。
第二，不要轻易 reset --hard，用 revert 或 stash 代替。对新手来说，revert和stash的安全性远高于reset --hard。我见过太多人因为reset --hard丢失了一天的工作量，那滋味真的不好受。
第三，配好.gitattributes文件再开始跨平台协作。如果你的项目可能被不同操作系统的人协作，比如有人用 Windows 有人用 macOS，一定要在项目初始阶段就配好.gitattributes，设置统一的换行符策略。等仓库积累了大量提交之后再处理，你面对的是每次拉取时满屏的换行符告警，心累到想弃坑。
第四，Windows 上遇到奇奇怪怪的 Git 行为，先怀疑 PATH 和凭据管理器。很多认知范围内的“灵异问题”，最后排查下来都是这两个配置在作怪。每次新装完 Git 建议顺手执行git config --global --list看一眼全局配置，有没有前人留下（或某些工具自动配置）的异常项，一眼就能识别。
Git 这个工具，刚开始用的时候会觉得命令又多又杂，但它的核心概念其实非常简洁：工作区、暂存区、本地仓库、远程仓库，四个池子之间搬运内容而已。等你把add、commit、push、pull、merge、stash这六个命令用顺了，再回头打开那些图形化工具或者 IDE 的 Git 面板，你会发现那些按钮背后都是这些命令的封装。到时候，你就从“会操作”迈向了“懂原理”的那一层。我个人的经验是，Windows 下顺手之后，换个 Linux 环境或者 Mac 用 Git，几乎零成本迁移——因为操作逻辑完全一样，真正的差异只是在终端工具的选型上。希望这篇从头到脚的实操分享，能帮你少走几步我已经走完的弯路。
