Git 这东西第一次在 Windows 上装十个人里有八个会被安装向导里那十几个单选框问懵。什么 Checkout Windows-style, commit Unix-style、什么 MinTTY、什么 credential helper一屏一屏往下点点完之后其实根本不知道刚才选了什么只知道git --version能蹦出版本号就算装好了。结果过两天拉下来一个别人写的仓库发现整个文件全是改动行或者中文文件名显示成一堆\346\226\207这种看不懂的字符再回头查才发现问题就埋在那几屏里。我把 Git 装在 Windows 上这套流程前前后后走了不下几十遍——自己的开发机、测试机、虚拟机、新同事的入职环境、甚至给别人做远程协助。踩过的坑基本覆盖了从下载哪个安装包到多平台账号怎么共存的所有环节。这篇就把 Windows 下 Git 的安装与配置整套流程摊开讲一遍从安装包怎么选、向导每一屏为什么这么选、装完之后必须改的几条配置一直到 SSH 密钥、凭据管理器、中文乱码、换行符这些真实会咬人的问题。适合完全没接触过版本控制的新手也适合装了 Git 但一直用得将将能用、想把它调顺手的人。文中所有操作步骤都是在 Windows 10/11 上实测过的命令可以直接复制执行。1. 装之前先想清楚Windows 上的 Git 到底在解决什么很多人对 Git 的理解停留在把代码传到网上的工具这个理解不算错但会直接影响你后面的选择。Git 本质上是一个分布式的版本控制系统它最核心的能力是记录每一次改动的快照并让你可以随时回到任何一个快照。往远端推送只是它的附加功能之一。搞清楚这一点你才会明白为什么安装向导里会有那么多看起来跟上传代码毫无关系的选项——因为它本来就不是一个上传工具。1.1 为什么 Windows 上必须单独装 Git而 Linux 和 macOS 不用Linux 上大多数发行版自带 Git 或者一条apt install git就完事macOS 装了 Xcode Command Line Tools 之后 Git 也就顺带有了。原因是 Git 最初就是 Linus 为 Linux 内核开发写的天然长在 Unix 环境里它的核心是一堆基于 POSIX 接口的 C 代码大量依赖 shell 脚本和各种 Unix 命令行工具。Windows 的内核和这套东西完全是两套体系所以 Windows 上的 Git 其实是Git for Windows这个项目——它把 Git 本体、一个精简的 MSYS2 环境、一套移植过来的 Unix 工具比如ls、grep、ssh、sed打包在一起再配一个叫Git Bash的终端模拟器给你用。你双击安装包装的不只是 Git而是一整个迷你 Unix 工具链。这解释了一个新手最常困惑的现象为什么装完 Git 之后突然多出来一个 Git Bash 窗口里面ls、pwd都能用但你在 CMD 里敲ls就提示找不到命令。因为那套工具只在 Git Bash 的内部环境里生效除非你在安装向导里做特殊选择把整个 Unix 工具链塞进系统 PATH。提示理解这一点之后你在网上看到的所有mkdir、rm -rf、export之类的命令就知道它们该在哪个窗口里执行。混用终端是新手排错时最大的干扰源。1.2 三条安装路线到底选哪条Windows 上装 Git 有三条主流路径各有各的适用场景不是越新潮越好。安装方式适合谁优点需要注意官网安装包.exe绝大多数人尤其是第一次装选项全可控卸载干净离线可用向导选项多需要知道每屏含义包管理器winget / Scoop已经习惯命令行、需要批量装环境的人一条命令搞定升级方便部分选项走默认值不好逐项控制便携版PortableGit无管理员权限、需要在U盘里带着走免安装不写注册表需要手动配环境变量和终端我的建议很直接第一次装就用官网的 .exe 安装包。不是因为它是唯一正确的而是因为它能让你把每一屏的选择都过一遍你在过程中建立的认知后面排错时值回票价。等你装过两三次、知道哪些选项雷打不动之后再考虑用 winget 批量部署。便携版除非你确实受限于公司电脑权限否则别碰环境变量的坑会消耗掉你省下来的那点时间。2. 下载与安装把向导每一屏都讲透这一节是整个流程里信息密度最高的部分。安装向导大概有十来屏大部分可以一路 Next但其中至少有四屏会直接影响你后面几个月用得舒不舒服。我会按顺序讲重点标出来。2.1 下载渠道与安装包类型怎么挑下载渠道只有一个值得信任的Git for Windows 的官方网站。直接搜 git for windows 进官网首页会自动识别你的系统位数并给出对应下载按钮。如果你的机器是近几年买的基本都是 64 位选64-bit Git for Windows Setup就行。页面上会看到几类文件别被绕晕Standalone Installer常规安装包就是我们说的 .exe推荐。Portable (thumbdrive edition)免安装版解压即用。MinGit极简版给嵌入式或者自动化脚本用的缺少 Git Bash 和大量工具普通人别下。版本号不需要纠结选最新的稳定版即可。Git 的兼容性做得很好新版几乎不会有破坏性变更。安装包大小大概在 60MB 上下一路涨到 70MB 左右如果下载到的文件只有几 MB大概率是下错了。注意不要去各种软件站下绿色版精简版免安装版。这类包经常被二次打包路径里塞了推广链接甚至改过默认配置。Git 本身免费开源官网直下没有任何门槛。2.2 安装向导逐屏解析重点看这四屏双击安装包之后的流程前面几屏是许可协议、安装路径、组件选择没什么好说的。装在哪由你路径里别带中文和空格这是通用经验能省掉后续一堆小概率问题。真正需要动脑子的是下面这几屏。第一屏Choosing the default editor默认编辑器Git 在很多场景下会拉起一个文本编辑器让你输入内容比如commit不写-m参数时、rebase交互式操作时。这一屏决定拉起的是谁。如果你平时用 VS Code强烈建议选Use Visual Studio Code as Gits default editor。选完之后 Git 会调用code --wait来打开编辑器--wait这个参数很关键它会让 Git 等编辑器关掉之后才继续执行否则你会看到 Git 命令一闪而过。如果你不用 VS Code选 Notepad 也比默认的 Vim 好——Vim 对没接触过的人是个灾难进去之后不知道怎么退出卡在那一屏半小时是常事。值得注意的一点这一屏的选择只是写进 Git 的全局配置后面随时可以用一条命令改掉不用担心选错了回不去。第二屏Adjusting your PATH environmentPATH 环境这一屏是全流程最重要的一屏它决定你能不能在任何终端里用git命令。三个选项Use Git from Git Bash only只有 Git Bash 窗口能用 gitCMD 和 PowerShell 都不认。除非你有特殊洁癖否则不要选。Git from the command line and also from 3rd-party software官方推荐项也是默认选中的。它会把 Git 加进系统 PATH同时把git相关的几个核心命令暴露出去但不会污染整个系统——不会把ls、find这些 Unix 命令也塞进去。Use Git and optional Unix tools from the Command Prompt警告项它会把整套 Unix 工具链放进 PATH。后果是 CMD 里的find、sort会被 Unix 版本覆盖某些老旧的 Windows 批处理脚本可能因此行为异常。选第二个。这一屏选错的最典型症状就是你在 PowerShell 里敲git --version返回git不是内部或外部命令也不是可运行的程序。遇到这个报错八成就是当初选了第一个选项或者安装时 PATH 没写进去。第三屏Configuring the line ending conversions换行符转换这一屏决定 Git 怎么处理换行符也是跨平台协作最容易翻车的地方。背景是这样Windows 上一行文本的结尾是两个字符CR LF回车换行而 Linux 和 macOS 上只有一个LF。如果不做处理Windows 上的开发者改了一个字符提交上去整份文件在 Linux 同事那边会显示成所有行都被修改了因为每一行的结尾都不一样了。三个选项Checkout Windows-style, commit Unix-style检出时把LF转成CRLF提交时把CRLF转回LF。这是 Windows 上的推荐项也是默认值对应的配置是core.autocrlftrue。Checkout as-is, commit Unix-style检出不动提交时转成LF。对应core.autocrlfinput适合在 Windows 上维护 Linux 项目的人。Checkout as-is, commit as-is什么都不转对应core.autocrlffalse。团队里都是 Windows 机器时可以用一旦有跨平台协作就会出问题。选第一个。这一屏选完之后我还会在后面的配置章节里再讲一遍因为它是那种你不主动确认一次就永远不知道自己是哪种状态的设置。第四屏Choose the default behavior of git pull这一屏决定git pull默认是 merge 还是 rebase。对新手来说选默认的Default (fast-forward or merge)就好。git pull引起的 merge 冲突是新手第一道坎但这个坎迟早要过早点遇到比在复杂项目里遇到好。等你对分支模型有感觉了再考虑切到 rebase 风格。其他几屏简单带过Choosing the SSH executable选Use bundled OpenSSH。用 Git 自带的那套别去接系统上别的地方装的 SSH省得环境变量互相打架。Choosing HTTPS transport backend选Use the OpenSSL library新版默认兼容性最好。Configuring the terminal emulator选Use MinTTY。它是 Git Bash 的默认终端比 Windows 老控制台好用太多支持窗口自由缩放、复制粘贴更顺手。Choose a credential helper选Git Credential Manager。这是下一个章节要重点讲的东西先选上。Configuring extra options两个勾都建议留着。Enable file system caching对性能有实打实的提升Enable symbolic links在处理某些仓库时是必需的。Configuring experimental options如果你会用 Node.js、Python 这类需要交互式输入的解释器把Enable experimental support for pseudo consoles勾上。不勾的话在 Git Bash 里跑node进 REPL 或者跑python交互模式会直接卡死没反应这是很多人遇到的Git Bash 里 python 用不了的根因。2.3 用 winget 一条命令装完如果你已经装过几次或者要给一批机器统一装命令行方式更省事。Windows 10 1809 之后自带 wingetwinget install --id Git.Git -e --source winget装完之后必须开一个新的终端窗口才能生效因为 PATH 的变更不会影响已经打开的进程。这是新手最常犯的错命令跑完了在原来那个窗口里敲git --version还是找不到然后以为装失败了。如果是 Scoop 用户scoop install gitScoop 版本默认不带 Git Credential Manager需要额外scoop install git-with-openssh或者手动补。这一点在选路线的时候要心里有数。3. 首次配置把该改的东西一次配到位安装完成只是把工具装进来了真正决定好不好用的是接下来这几条配置。很多人装完 Git 直接就用然后被乱码、换行符、默认分支名这些问题反复折磨其实都是几条命令的事。先看 Git 配置的层级结构这个搞清楚之后所有配置问题你都能自己定位。3.1 三个配置层级system、global、localGit 的配置是分层覆盖的一共三层优先级从低到高层级作用范围配置文件位置写入命令system整台机器所有用户Git 安装目录下etc/gitconfiggit config --systemglobal当前用户所有仓库C:\Users\你的用户名\.gitconfiggit config --globallocal当前这一个仓库仓库内.git/configgit config --local同一个配置项如果 local 里有就用 local 的local 没有就看 globalglobal 没有就看 system。这个覆盖规则非常有用比如你可以在 global 里配一个默认邮箱在某个特定仓库里用 local 覆盖成公司邮箱。日常 90% 的配置都是往 global 里写。查看当前所有配置以及它们分别来自哪个文件用这条命令git config --list --show-origin这个命令是我排错时的第一选择。任何时候你觉得我明明配了啊怎么不生效跑一下它立刻能看到这个值到底是从哪个文件读出来的、有没有被更高层级覆盖。注意~/.gitconfig这个文件本质上就是个纯文本 INI 文件你可以直接用编辑器打开手改。但如果改的时候格式写坏了比如少了个引号、多打了个制表符Git 会报bad config line N in file然后所有 git 命令都执行不了。所以改之前先备份或者养成用git config命令改的习惯。3.2 身份标识和默认分支名装完立刻改装完 Git 之后第一件事是配身份。Git 的每一次提交都会记录作者名和邮箱这两个信息直接写进提交历史是永久性的。配错了后面要改就得重写历史很麻烦。git config --global user.name 你的名字 git config --global user.email 你的邮箱example.com邮箱这里有个实际建议如果你要在 GitHub、Gitee、GitLab 这些平台上提交邮箱最好和你在平台上注册的邮箱一致。平台就是靠邮箱来把提交记录关联到你的账号头像上的邮箱对不上提交记录虽然在但不会计入你的贡献统计也不会关联到你的头像。这是很多人提交了但没算我头上的原因。第二件事是改默认分支名git config --global init.defaultBranch mainGit 2.28 之后支持这个配置。git init默认创建的分支名从master变成了main因为主流代码托管平台都已经把默认分支改成main了。如果你不配这一条本地新建的仓库是master推上去之后还要在平台上改默认分支多一步操作。安装向导里其实也有这一屏Adjusting the name of the initial branch选了 Override 到main就等价于这条配置。第三件事如果你用 VS Code把默认编辑器也定下来git config --global core.editor code --wait3.3 换行符装完必须确认一次的配置前面安装向导里讲过换行符这里再确认一遍因为这是唯一一个装有装错、你还很难立刻发现的配置。git config --global core.autocrlf trueWindows 单机开发、以及和跨平台团队协作都用true。它的行为是从仓库检出文件时把LF换成CRLF提交时把CRLF换回LF。这样你本地编辑时是 Windows 习惯的换行仓库里存的永远是统一的LF两边都不难受。如果你维护的是明确要求LF的项目比如很多开源项目会在.gitattributes里强制指定可以改成input意思是检出时不动提交时才转换。配完之后怎么验证在一个已有仓库里跑git config core.autocrlf它会返回当前仓库实际生效的值。如果项目根目录下有.gitattributes文件那里面的规则优先级高于core.autocrlf因为它是跟着仓库走的团队里每个人都会被强制成同一套规则——这也是推荐的做法用.gitattributes来统一团队的换行符策略比每个人自己配可靠得多。提示如果你已经在一个仓库里遇到整个文件都被标记为修改的情况先别急着提交。跑git diff --stat看一眼是不是所有行都变了如果是大概率就是换行符问题。最省事的解法是在项目里补一个.gitattributes内容写* textauto eollf然后重新检出文件。3.4 中文乱码的三处根因逐个解决中文乱码是中文用户在 Windows 上用 Git 的高频问题症状有三种根因各不相同别混为一谈。症状一中文文件名显示成一串八进制转义字符比如文档.txt显示成\346\226\207\346\241\243.txt。这是 Git 为了兼容终端默认对非 ASCII 文件名做了转义。解决办法git config --global core.quotepath false这一条几乎是我装完 Git 之后的必配项。配完之后git status里的中文文件名就正常显示了。症状二提交信息commit message里的中文显示成乱码这个通常跟提交编码有关git config --global i18n.commitEncoding utf-8 git config --global i18n.logOutputEncoding utf-8现代 Git 默认就是 UTF-8一般不用改。真正的原因往往在终端本身——Git Bash 默认字符集如果被设成了别的就会花屏。检查 Git Bash 窗口左上角图标右键 → Options → Text确认 Character set 是 UTF-8。症状三命令输出比如git log里的中文乱码这通常和分页器有关。git log默认用less翻页如果less不认识 UTF-8中文就会显示成乱码。解决办法是设置LESSCHARSETexport LESSCHARSETutf-8如果你希望永久生效可以把它写进~/.bashrc里。不过对大多数用户来说更简单粗暴的方案是让 Git 别用分页器git config --global core.pager 代价是git log会一次吐一屏长历史会刷屏。我个人用的是折中方案保留分页器但配一条别名git config --global alias.lg log --oneline --graph --all日常看历史用短格式基本不会出现中文问题。3.5 别名和其他值得一次性配好的项Git 有几十个常用命令敲全称挺累的。别名alias就是给自己开快捷键git config --global alias.st status git config --global alias.co checkout git config --global alias.br branch git config --global alias.ci commit git config --global alias.lg log --oneline --graph --all --decorate git config --global alias.last log -1 HEAD --stat git config --global alias.unstage reset HEAD --配完之后git st就等于git statusgit lg直接给你一张带分支图的历史比默认log可读性高一个量级。git unstage用来把误add的文件撤出暂存区比记git reset HEAD --舒服得多。另外两条值得配的git config --global core.longpaths true git config --global pull.rebase falsecore.longpaths true解决的是 Windows 上经典的 260 字符路径长度限制问题。前端项目尤其是 Node.js 生态依赖层级动不动就嵌套七八层node_modules里的路径长度非常容易超限报错信息通常是Filename too long或者unable to create file。这一条配上能省掉一大堆莫名其妙的错误。注意它需要系统层面的长路径支持Windows 10 之后默认是开启的。pull.rebase false是明确告诉 Gitpull时用 merge 而不是 rebase避免 Git 在版本更新后提示你设置这个值。4. 密钥与凭据别每次都输密码到这一步 Git 本地已经能用了但每次push都弹窗让你输账号密码用起来会很想砸键盘。这一节解决的就是身份认证问题有两条路线SSH 密钥和凭据管理器。4.1 SSH 密钥一次配置长期免密SSH 密钥是一对文件公钥和私钥。私钥留在你自己机器上绝不外传公钥交给代码托管平台。之后你往平台推代码时平台拿公钥验证你的身份全程不用输密码。生成密钥的命令在 Git Bash 里执行ssh-keygen -t ed25519 -C 你的邮箱example.com推荐用ed25519而不是老的rsa。原因是 ed25519 密钥更短、生成更快、安全性更好而且现在所有主流平台都支持。如果你的环境比较老必须用 rsa那就加上长度参数ssh-keygen -t rsa -b 4096 -C 你的邮箱example.com命令执行过程中会问你三个问题保存路径直接回车用默认值~/.ssh/id_ed25519。如果这台机器上已经有一对密钥、且你有别的用途可以另起一个文件名比如~/.ssh/id_ed25519_work。设置密码短语passphrase可以直接回车留空使用上最省事。如果设了密码每次用密钥都要输入可以配合 ssh-agent 缓存。确认密码同上。生成完之后查看公钥内容cat ~/.ssh/id_ed25519.pub输出是一行以ssh-ed25519开头的字符串。注意是.pub结尾的那个文件别把没有.pub后缀的私钥内容复制出去。把这一整行复制到平台后台的 SSH Keys 设置里粘贴保存即可。验证连通性ssh -T gitgithub.com第一次连接会提示确认主机指纹输入yes回车。如果返回类似 Hi 你的用户名! Youve successfully authenticated 的信息就说明通了。返回Permission denied (publickey)的话往下看常见问题那一节。注意私钥文件没有.pub后缀的那个权限设置很关键绝对不能提交到任何仓库里。如果你不小心把私钥推到了公开仓库立刻去平台后台删除对应的公钥并重新生成一对因为私钥一旦泄露任何拿到它的人都以你的身份操作。4.2 Git Credential ManagerHTTPS 路线的免密方案如果你用的是 HTTPS 协议而不是 SSH靠的是凭据管理器。安装向导里选了 Git Credential Manager 的话第一次push时它会弹出一个窗口引导你完成授权之后把凭据存进 Windows 凭据管理器后续操作就不再问了。查看当前用的凭据助手git config --global credential.helper如果返回manager或manager-core说明配置正常。返回空的话补一条git config --global credential.helper manager两种路线怎么选我的经验是这样个人开发机、长期用同一批账号SSH 更省心一次配好基本不用管。公司电脑、需要频繁切换账号、或者受网络策略限制凭据管理器更合适它的授权走的是账号密码/令牌流程不依赖端口。需要同时往多个平台推代码SSH 配合多密钥配置更清晰。另外要说明一下现在 GitHub 已经不再支持账号密码直接推送了必须用个人访问令牌Personal Access Token。如果你用 HTTPS 方式密码那一栏要填令牌而不是登录密码。这也是很多人push时报Authentication failed的原因。4.3 多账号共存一台机器配两套身份现在很多人都有这种情况一个私人账号一个公司账号甚至三个平台各一个。默认情况下 Git 会用同一套身份和同一把密钥推错账号是常事。身份切换用includeIf按目录自动切# 工作目录用公司邮箱 git config --global includeIf gitdir:D:/work/ .pathofwork git config --file ~/.gitconfig-work user.name 公司名字 git config --file ~/.gitconfig-work user.email 你的公司邮箱 # 个人目录用私人邮箱 git config --global includeIf gitdir:D:/personal/ .pathofpersonal git config --file ~/.gitconfig-personal user.name 个人昵称 git config --file ~/.gitconfig-personal user.email 你的私人邮箱规则是凡是位于D:/work/目录下的仓库自动读取~/.gitconfig-work里的配置其余走全局配置。注意gitdir:后面的路径结尾必须带斜杠这是最容易写错的地方少了斜杠匹配不上而且还不会报错你会以为配了但完全没生效。密钥切换靠 SSH 配置文件。创建或编辑~/.ssh/configHost github-work HostName github.com User git IdentityFile ~/.ssh/id_ed25519_work Host github-personal HostName github.com User git IdentityFile ~/.ssh/id_ed25519_personal用的时候把远程地址里的github.com换成你定义的别名git remote set-url origin gitgithub-work:公司组织/仓库名.git这样一条git push会走工作密钥另一条走个人密钥互不干扰。这套配置我用了很久是解决多账号打架最干净的方案。5. 验证与实战从第一次提交到问题排查配置全部做完该验证一遍了。这一节给出一套完整的检查清单和实操流程然后是一份常见问题的速查表。5.1 十分钟验证清单按顺序跑下面这些命令任何一条返回异常就回到对应章节检查# 1. 确认 git 能被找到以及版本 git --version # 2. 确认 git 命令实际来源路径Windows 上用 where where git # 3. 查看所有生效配置及来源 git config --list --show-origin # 4. 确认身份 git config --global user.name git config --global user.email # 5. 确认换行符策略 git config core.autocrlf # 6. 确认中文路径显示正常 git config core.quotepath # 7. 确认凭据助手 git config --global credential.helper重点说第 2 条。where git在 Windows 上会列出所有叫git的可执行文件路径。如果你之前装过别的东西带了 git比如某些 IDE 自带的这里可能返回两三行。排在前面的那个才是实际生效的。我就遇到过 IDE 自带的老版本 Git 排在系统安装版前面导致无论怎么升版本号都不变的情况。发现这种冲突就去环境变量里把那一条挪走。5.2 第一次完整流程从零到一个提交验证完环境走一遍完整流程把每个命令的意图讲清楚# 建一个练习目录并进入 mkdir git-demo cd git-demo # 初始化仓库会生成一个隐藏的 .git 目录 git init # 看一眼当前状态应该提示 no commits yet git status # 创建一个文件 echo hello git readme.txt # 再看状态readme.txt 是红色未跟踪状态 git status # 加入暂存区 git add readme.txt # 状态变绿说明已暂存 git status # 提交 git commit -m first commit # 查看历史 git log --oneline这里有三个概念新手容易混工作区你实际编辑文件的地方、暂存区git add之后文件停留的地方、本地仓库git commit之后进入的地方。git status之所以重要是因为它随时告诉你某个文件处于这三个区域的哪一个。红色是工作区有改动但没暂存绿色是已暂存但没提交什么都不显示就是三个区域一致。git add和git commit为什么要分两步因为这样你可以选择性地提交——改了五个文件但只想把其中两个相关的改动做成一次提交另外三个分到另一次提交里去。这是 Git 相比很多老式版本控制工具的核心优势之一。接下来关联远端并推送git remote add origin gitgithub.com:你的用户名/仓库名.git git branch -M main git push -u origin main-u参数的作用是把本地main和远端origin/main建立追踪关系之后在main分支上直接敲git push和git pull就行不用再带参数。第一次推送会校验密钥或凭据走通之后就顺畅了。5.3 和编辑器的衔接VS Code 与 IDE 的 Git 集成命令行用熟了之后日常的查看改动、暂存、提交其实在编辑器里做效率更高。VS Code 内置了 Git 支持打开一个有.git目录的文件夹左侧活动栏就会出现源代码管理图标能看到所有改动文件、逐行 diff、快捷提交。如果 VS Code 里提示找不到 Git去设置里搜git.path填上git命令的完整路径用where git查到的那个。绝大多数情况下它自己能找到找不到通常是 PATH 里有多个 Git 冲突。几个我常用的集成习惯在 VS Code 里写 commit message 比命令行舒服因为有换行和多行编辑可以写清楚标题和正文。提交前一定先看 diff。VS Code 点文件就能看到逐行对比比git diff在终端里刷屏直观得多。别在 IDE 里直接点提交并推送尤其在团队项目里。先提交到本地跑一遍测试或者至少检查一下git status确认没有把临时文件、配置文件、密钥文件带进去再推。顺带提一句.gitignore。项目根目录下建一个这个文件把不需要版本控制的东西写进去比如node_modules/、*.log、.env、IDE 的.idea/目录。有一个新手极易踩的坑.gitignore只对未被跟踪的文件生效。如果某个文件之前已经被git add过你再往.gitignore里加是没用的它照样被跟踪。这时候要先把它从跟踪列表里移除git rm -r --cached 文件或目录名--cached的作用是只从 Git 的跟踪列表里移除本地文件不会被删。这个参数忘了加文件就真被删了是很多人手抖出事故的地方。5.4 常见问题速查表下面这些是 Windows 上用 Git 最高频的报错按症状、根因、解法整理遇到问题直接对着查。报错 / 症状大概率原因处理方式git不是内部或外部命令PATH 里没有 Git或装了但没重开终端检查安装向导第二屏重开终端用where git确认Permission denied (publickey)公钥没上传或密钥不匹配ssh -T测试确认平台后台公钥与本地.pub一致多密钥时检查~/.ssh/configAuthentication failedHTTPS用了登录密码而不是访问令牌生成个人访问令牌用它当密码或改用 SSH中文文件名显示成\346\226\207core.quotepath为 truegit config --global core.quotepath falseLF will be replaced by CRLF警告换行符转换提示通常无害确认core.autocrlf设置项目中用.gitattributes统一整个文件都被标记为修改换行符不一致git diff --stat确认配.gitattributes重新检出Filename too longWindows 路径长度限制git config --global core.longpaths truebad config line N in file配置文件格式写坏了打开.gitconfig检查该行或删掉重建.gitignore不生效文件已被跟踪git rm -r --cached 文件后重新提交Git Bash 里python/node卡死未开伪终端支持重跑安装包勾选 pseudo consoles或用winpty python推送到错误的账号多账号身份未隔离用includeIf按目录区分身份SSH 用config别名区分密钥提交记录不显示在平台头像上提交邮箱与平台账号邮箱不一致改user.email后续提交即可关联其中我想特别强调整个文件都被标记为修改这一条。它的迷惑性极强因为git status只是普通地显示文件被修改了你点进去看 diff 又好像每行都一样肉眼根本看不出区别。养成习惯动辄看到几十上百个文件被修改先怀疑换行符别先怀疑自己。跑一下git diff --stat如果显示每个文件都是全部行数 N -N那就是了。还有一条经验跟在团队里协作有关.gitattributes比个人配置可靠。因为它跟着仓库走新克隆的人自动就被套上了同一套规则不依赖每个人自己去配core.autocrlf。新建项目时我一般会在根目录放一个内容就两行* textauto *.sh text eollf第一行让 Git 自动判断文本文件并统一成LF存储第二行强制 shell 脚本在任何平台上检出都是LFshell 脚本带CRLF在 Linux 上跑会直接报错这是个很隐蔽的坑。我个人在实际操作中的体会是Git 的安装配置这件事值的不是那十几屏选项本身而是你在走这个流程时被迫理解的几个概念分层配置的覆盖关系、换行符的跨平台差异、暂存区的存在意义、以及身份认证的两条路线。这几件事一旦想明白后面无论遇到什么报错你都能大致判断问题出在哪一层而不是漫无目的地搜报错。装完之后别急着删安装包等你在真实项目里跑通一次完整的提交和推送再清理也不迟。