不用怀疑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 TerminalWin11 自带或 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 里能用 GitCMD 里敲git找不到命令。Git from the command line and also from 3rd-party software推荐默认把 Git 加到系统 PATHCMD、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 gitgithub.com如果你是 GitHub 用户会看到类似Hi 用户名! Youve successfully authenticated, but GitHub does not provide shell access.的输出。看到这行字说明 SSH 通了公钥配置成功从此以后免密操作。如果是 Gitee命令换成ssh -T gitgitee.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 gitgithub.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: 修复列表页白屏问题。好的提交信息是给未来的自己看的别写“修改了一些东西”这种没用的话。如果你没加-mGit 会打开你配置的编辑器让你填写提交信息这就是为什么之前建议你选 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 打开时路径跳到了错误的位置。排查方式先执行pwdGit Bash 里或cdCMD 里看当前路径再执行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 默认用的是managerWindows 凭据管理器一般是安全的但如果你之前手动配置过credential.helper store就可能会收到这个警告因为store模式是把密码明文写在~/.git-credentials文件里的。解决办法把凭据管理器切回 Windows 凭据管理器git config --global credential.helper manager如果你发现某天 Git 操作总是提示认证失败大概率是凭据管理器里的条目过期或者被改了。去 Windows 凭据管理器里找到对应的git:https://...条目删掉重新操作一次就会弹出登录框让你重新输入不会丢失任何代码数据。5.4 Git LFS 安装与使用注意如果你的项目里有大文件比如设计稿、模型文件、视频素材普通 Git 仓库会很快变得臃肿克隆速度直线下降。Git LFSLarge 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 initPermission denied (publickey)SSH 私钥未被识别确认私钥路径ssh-add ~/.ssh/id_ed25519Please make sure you have the correct access rightsSSH 公钥未配置到平台检查平台 SSH 公钥列表是否已添加failed to push some refs to远程有本地没有的提交先git pull再git pushwarning: LF will be replaced by CRLF换行符规则配置不一致配置.gitattributes统一换行符terminal is not fully functionalGit Bash 终端类型不兼容在 Git Bash 中设置export TERMxtermunable to access https://...: SSL certificate problemHTTP 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几乎零成本迁移——因为操作逻辑完全一样真正的差异只是在终端工具的选型上。希望这篇从头到脚的实操分享能帮你少走几步我已经走完的弯路。