Git 误操作这件事几乎所有开发人员都经历过而且大概率不止一次。我就见过不少同事辛苦写了一下午的代码因为一个git reset --hard或者git branch -D直接回到解放前那个表情我这辈子都忘不了。所以当我看到这个项目标题第一反应是——确实需要这样一篇整理把那些让人手心冒汗的瞬间一个一个拆开说清楚背后发生了什么下次遇到时怎么处理才不会慌。这篇文章不打算讲特别高深的内核原理也不做命令大全式的罗列就是围绕实际工作中最高频的 Git 翻车现场从新手的坑一路聊到老手也会碰上的高级救场场景。每个小节都有真实操作、有命令、有推导过程的思路结合我这些年实际踩坑和帮别人救场的经验尽量做成一份“事故时可查、平时可学”的手册。无论你是刚装好 Git 正在跟git not found搏斗的初学者还是需要用reflog抢救丢失提交的中级开发者这篇文章都应该对你有帮助。1. 安装与环境配置的那些坑很多 Git 的问题表面上是“命令报错”实际上源头是安装和配置环节就没弄好。这一节先把最基础也最容易劝退新手的几个坎讲透。你在搜索引擎里看到“git安装及配置教程”“git不是内部或外部命令”“git下载安装教程”这类词高频出现说明卡在这一步的人非常多。1.1 git 不是内部或外部命令八成是 PATH 没配好在 Windows 上最常见的第一课就是打开 cmd 或者 PowerShell敲git --version然后看到一行提示“git 不是内部或外部命令也不是可运行的程序或批处理文件。” 或者你在 VSCode 的终端里看到“无法将“git”项识别为 cmdlet、函数、脚本文件或可运行程序的名称。”这个报错的本质是系统在 PATH 环境变量里遍历所有目录也没找到git.exe这个可执行文件。我见过不少新手安装 Git 的时候一路 Next把默认选项全部跳过而默认安装界面里有一项叫 “Adjusting your PATH environment”如果没选对Git 装完了但系统找不到自然就报错。解决办法分两种。第一种如果已经装好 Git 但 PATH 不对那就手动把 Git 的安装路径加进去。比如笔者的 Git 装在D:\Git那 PATH 里就需要加入这两个路径D:\Git\bin D:\Git\cmd在 Windows 11 / 10 上按 Win 键搜索“编辑系统环境变量”打开“环境变量”找到用户变量或系统变量里的Path点编辑新增上面两行然后重新打开一个终端窗口注意已经打开的终端不会刷新环境变量再执行git --version就能看到了。第二种更省事重装 Git。安装到 “Select Components” 或 “Adjusting your PATH environment” 那一步时选择 “Git from the command line and also from 3rd-party software” 或者 “Recommended” 选项安装器会自动把 PATH 配好。这里我建议新手直接选 Recommended后面少很多折腾。另外补充一句很多朋友习惯用 Git Bash 来跑命令这个终端本身是随 Git 一起安装的启动之后就已经把环境切到了 Git 的 bash 环境里相对不容易出现找不到命令的情况。如果 Bash 也打不开大概率是安装包本身有问题建议重新下载官方 64 位版。1.2 error setting certificate file证书配置引起的远程访问失败你兴致勃勃地git clone一个仓库结果终端给你蹦出来一长串unable to access https://xxx.git/: error setting certificate file: d:/git/mingw64/etc/ssl/certs/ca-bundle.crt这里我直接说结论Git 在通过 HTTPS 访问远程仓库时需要用到 CA 证书来验证服务端的身份。上面的报错是 Git 在初始化 SSL 时去找证书文件发现路径下不存在或者文件读取失败。常见诱因有这几个你曾经改过 Git 的安装路径或者移动过整个 Git 安装目录导致默认证书路径失效。公司电脑上装了某些安全软件或代理把证书文件给隔离了。Git 配置里被写入了错误的http.sslCAInfo或http.sslCAPath值。处理思路也很直接先执行git config --list --show-origin看下有没有和 ssl 相关的配置特别是全局配置或系统配置里是否残留了一个失效路径。如果有用下面命令删掉或改成正确的值git config --global --unset http.sslCAInfo git config --global http.sslCAInfo D:/Git/mingw64/etc/ssl/certs/ca-bundle.crt如果确实证书文件缺失可以到 Git 安装目录下检查正常路径应该存在ca-bundle.crt。没有的话重新安装 Git 是最快的方案或者从可信源把证书包放回去。还要提醒一句网上很流行让人直接执行git config --global http.sslVerify false来绕过证书校验这套对于应急确实快但本质上等于告诉 Git“我不验证对方身份了”。如果是内部测试环境临时用用可以访问正式服务器尤其是涉及敏感代码库时不建议长期开着不然等于给中间人攻击留了一扇门。1.3 git set proxy网络代理配置和排查我见过很多人 clone 仓库一直卡住、超时最后发现是代理配置在捣鬼。常见的像git config --global http.proxy http://127.0.0.1:1080这种设置是为了让 Git 走本地代理访问外网仓库。问题是代理有时会挂、会变或者你根本不需要代理了但配置一直留着然后所有远程操作都开始报错。排查代理配置我用这三个命令git config --global --get http.proxy git config --global --get https.proxy git config --global --list | grep -i proxy确认是不需要的代理直接清掉git config --global --unset http.proxy git config --global --unset https.proxy另外除了全局配置还要小心环境变量HTTP_PROXY、HTTPS_PROXY或ALL_PROXY。因为 Git 会读取这些环境变量来设置代理。我之前遇到过全局配置里什么都没设但终端依然走代理最后排查了一圈问题出在系统环境变量里。用echo $HTTP_PROXY能看得很清楚有值的话unset HTTP_PROXY或者从系统环境变量里删掉。2. 新手最容易踩的误操作与当场救回这一节是真正的“急救”内容也是我在论坛和群里被问得最多的一类问题。Git 本身的设计是安全可靠的问题是很多人只知道往前提交不知道出事后怎么回头。下面这三板斧务必要背下来。2.1 刚提交了不该提交的文件撤销暂存区和提交很多人的工作流是这样的在项目里一顿操作然后git add .再git commit -m xxx提交完才发现把.env文件、node_modules或者一堆编译产物提交上去了。这个时候不要慌分两种情况处理。情况一只想把文件从暂存区撤出来但保留工作区的改动。这种情况最常见于你执行了git add但还没 commit想把某个文件从“待提交列表”里去掉。用git restore --staged file旧一点的 Git 版本用的是git reset HEAD file两者效果一样。注意git reset HEAD这个命令在 Git 2.23 之后其实已经不太推荐用于“撤销暂存”的用途官方更推荐git restore --staged但很多老教程还在用所以我两边都写出来方便你遇到什么问题都能对上号。情况二已经 commit 了想撤销这次提交但保留改动在暂存区或工作区。用git reset --soft HEAD~1--soft的意思是把 HEAD 指回上一次提交但暂存区和工作区的内容都不动。这样你就有机会重新整理文件再分成多个更合理的提交。如果你连暂存区的内容也不想要了想回到某个文件“未 add 也未 commit”的状态那就用git reset HEAD~1这个不带参数的 res 实际上是--mixed它会重置暂存区但保留工作区文件内容。注意reset只适合处理本地尚未推送的提交。如果提交已经 push 到远程仓库尤其是多人协作的分支尽量不要用reset去改历史而是用后面要讲的git revert。2.2 误删了文件restore 帮你捞回来一个很常见也很气人的场景本来想整理一下项目结构一个rm删掉了某个源码文件结果发现没备份、没提交过最新版本瞬间大脑一片空白。其实只要这个文件在你的工作区里被 Git 跟踪过且本地 HEAD 上的版本还包含它就能恢复。如果文件只是被删除了还没执行过其他操作git restore file更稳妥一点直接把文件从 HEAD 里恢复到工作区git checkout HEAD -- file理解一下这条命令的逻辑checkout从指定的 commit这里写的是 HEAD中取出文件覆盖到当前工作区。所以只要是提交过的文件不管删了多少次都能捞回来。但如果你不光删了文件还顺手用git add把删除操作也暂存了也不用怕。先撤销暂存再用上面的命令恢复按顺序来git restore --staged deleted_file git restore deleted_file2.3 改乱了文件想撤销checkout 与 restore 的选择玩 Git 的新手经常会把工作区里的文件改得乱七八糟想直接回到上一版的“干净”状态。这种情况下git restore file或者老命令git checkout -- file它们的作用都是放弃工作区对文件的修改回到当前 HEAD 里的版本。这条命令的杀伤力巨大因为工作区的改动会被直接覆盖没有回收站。在敲回车之前千万要确认这个文件里没有你还需要的东西。我自己的习惯是在不确定改动是否还要保留时先git stash把改动存入暂存堆栈再决定要不要彻底丢弃。比如git stashstash把你的工作区改动和暂存区改动都保存到 stash 堆栈里工作区回到干净状态。如果后面反悔了用git stash pop就能恢复。这条路的容错率比直接restore高得多。2.4 提交信息写错了amend 修改最近一次提交提交完了才发现 commit message 写成了“fix bug”你想改成“fix: 修复登录接口返回 500 问题”或者漏了一个文件想补进去。只要这次提交还没推送到远程就可以用git commit --amend -m fix: 修复登录接口返回 500 问题这个命令的作用是“改写最近一次提交”不只是改 message如果之前忘了git add某个改动可以 add 之后直接git commit --amend把新改动并入上一次提交也不会增加一条新的提交记录。但要注意--amend会生成一个新的 commit 对象本质上是修改了历史。如果这个提交已经被别人拉取过或已经推送到了公共分支再去 amend 就会造成历史分叉别人 push 的时候会冲突。团队协作时对已推送的提交不要用 amend。3. 分支操作翻车现场合并冲突与删错分支分支操作是 Git 使用中的一个分水岭很多人就是从这里开始真正理解 Git 的。但也是从这里开始会有各种“合并完发现不对”“分支删了找不回”的事故。3.1 git merge 冲突了想放弃合并怎么办合并分支时遇到冲突很正常Git 会停下来让你手动解决把冲突标记、、留在文件里。新手面对一堆冲突标记容易心态爆炸有时就想“我不合了总行吧”。工具已经给你留了后悔药git merge --abort这个命令会中止当前的合并过程试图恢复到合并开始前的状态。注意它和git merge --quit不同--abort会回滚到 merge 之前的状态而--quit只是忘掉当前合并进行中这个状态工作区的冲突文件并不会被还原。这里有个细节如果在 merge 过程中你手动修改过某些文件并git add了git merge --abort仍然会尝试恢复原状但如果你在冲突解决过程中做过超出 Git 预期的操作比如手动 git commit--abort有时会失败让你先手动处理。此时可以用git reset --merge或者直接git reset --hard HEAD回到合并前的位置但要清楚硬重置的风险。3.2 删错分支怎么找回reflog 和 origin 双保险git branch -D old-branch是很多人清理本地分支时常用的命令问题是-D大写意味着强制删除不检查分支是否已经合并。如果误删了一个上面还有独有提交的分支第一反应千万不要慌提交对象并没有真正消失只是分支指针被摘掉了。找回方法用 refloggit reflogreflog 是 Git 的“操作日志”记录了 HEAD 指针每次移动的历史。哪怕分支被删只要上面最后一次提交的 SHA 值还能在 reflog 里找到就能重建分支。比如日志里看到一行a1b2c3d HEAD{2}: commit: feat: add login module那执行git branch old-branch a1b2c3d就能把分支从a1b2c3d这个提交上重新拉回来。如果本地没有 reflog 记录比如仓库刚 clone或者被 GC 清理过另外一种思路是去远程仓库看。只要这个分支曾经推送过大概率还在远程仓库上重新拉取一个本地分支并跟踪远程即可git checkout -b old-branch origin/old-branch这也是我一直强调的重要分支尽量推送到远程万一本地炸了远程还能兜底。3.3 合并错了要回退revert 与 reset 的选型合并完发现代码有问题或者合并了不该合的分支这类事故在团队协作里太常见了。回退手段有两种选择取决于这个合并是否已经推送以及是否被别人用过。如果合并只存在于本地还没有推送直接用git reset --hard merge之前的commit这样干净利落整个分支回到合并前的位置。如果合并已经推送到远程或者不确定别人有没有基于这个合并做过开发那不要用 reset 改历史应该用git revert -m 1 merge_commit_sha这里的-m 1表示保留合并提交的第一个父提交通常是主分支当前的位置撤销另一个分支带来的改动。revert 会生成一个“反向提交”的新提交历史是往前走的不会破坏已有的提交记录所以能被团队安全拉取。我经常看到一些人不分情况一律reset --hard然后 force push 把远程搞乱这在多人协作里非常危险。记住一个原则没推送的用 reset推送过的用 revert除非你确定自己是这个远程分支的唯一用户并且能接受强制推送带来的协作问题。4. 远程仓库与认证问题本地操作虽然麻烦但至少不会直接影响到别人。远程仓库一旦出问题报错五花八门而且经常和环境、代理、凭证相关排查起来更费劲。这一节把和远程相关的典型问题一次性说清楚。4.1 fatal: not a git repository 是怎么回事这个报错常常让新手一脸问号我明明在项目里为什么说这不是一个 Git 仓库其实原因很简单当前目录没有.git目录。具体场景有几种。第一种你进入了一个子目录但 Git 仓库的初始化或 clone 发生在上一级目录。比如仓库在D:\project你跑到D:\project\src下执行git status正常情况下 Git 能自动向上查找找到.git但如果D:\project本身也是个独立项目目录且没有.git那就会报错。第二种你在仓库目录里执行命令时当前终端的工作目录已经变了比如用 Git Bash 进入了一个临时目录。第三种比较隐蔽项目的.git目录被误删了或者从压缩包解压时丢了隐藏文件。处理方式很简单先pwd确认当前目录再用ls -a看有没有.git。如果项目是通过git init初始化的没有.git就是初始化失败或被误删重新git init即可。但注意重新 init 并不会影响已有文件的修改记录当然历史也没了因为原来那些提交对象都保存在.git里。如果确实存在.git目录却还是报错再看一眼.git是不是一个文件而不是目录。Git 支持使用“gitdir: path”格式的.git文件来指向实际仓库目录这在 submodule 和工作树分离的场景里很常见。如果.git文件内容里的路径不对也会出这个错。4.2 git clone 配置账号密码免密配置的三种正确姿势新 clone 一个私有仓库Git 大概率会弹出账号密码验证。很多公司内部 GitLab 还会要求使用 Token 而不是账号密码这时候网上的教程往往不统一导致一波人卡住。第一种方式直接在 clone 的 URL 里带上账号信息git clone https://username:passwordgithub.com/owner/repo.git这种方式最快但不推荐因为 URL 会出现在 shell 历史、打包脚本、日志等地方密码明文暴露。如果只是临时用用完建议马上改掉远程 URL。第二种方式使用凭证存储git config --global credential.helper store这样 Git 会在首次输入用户名密码或 Token后把凭证明文保存在~/.git-credentials里。省事但同样是明文保存的机器要靠谱一点。第三种方式也是我认为最推荐的方式使用 SSH Key。生成密钥对把公钥放到 GitLab 或 GitHub 上然后把远程 URL 切换成 SSH 格式git remote set-url origin gitgithub.com:owner/repo.gitSSH 免密的好处是密钥可以设置 passphrase甚至可以配合 ssh-agent 实现一次输入多次使用安全性明显更高。公司内部如果允许走 SSH 协议强烈推荐这种方式。4.3 Login failed: check api token or gitlab version这个报错多见于使用 IDE 里的 Git 插件比如 IntelliJ IDEA 的 GitLab 插件或者某些第三方 Git GUI 工具。报错全文大致是Login failed. Check API token or GitLab version. Log in via Git if the version is unsupported.它说明的不是 Git 命令本身的问题而是 IDE 插件调用 GitLab API 时认证失败或协议不匹配。常见诱因Token 过期或者权限被撤销。GitLab 版本太老新版本插件不再兼容旧 API。IDE 缓存了旧的 Token。解决思路先去 GitLab 个人设置里重新生成一个 Token注意勾选必要的权限api、read_repository等再到 IDE 的 GitLab 设置里更新。如果确认 Token 没问题大概率是版本兼容问题可以考虑升级 GitLab 或换用 IDE 自带版本控制不安装独立插件来处理。4.4 远端 URL 异常如何修改 remote有时候你想给仓库换远程地址或者从 HTTPS 切到 SSH很多人会直接删掉 remote 再重新加git remote remove origin git remote add origin new_url这样做虽然行但会丢失一些已有的远程跟踪分支配置。更平滑的做法是用set-urlgit remote set-url origin new_url改完之后可以用git remote -v查看是否生效。这个方法尤其适合“同一个远程仓库换了地址”的场景不仅能保留远程分支配置也避免删除 remote 期间误操作。5. 高级救场reflog 与 reset 后的绝地求生到了这一节是真正能体现 Git 功力的时候。前面那些操作解决的是“人还在、东西丢了”的问题这一节要解决的是“看起来连根都没了”的场景。我敢说这个标题下“高级救场”四个字最核心的技术点就是 reflog。5.1 reflog 到底是什么为什么能救回“丢了”的提交先忘掉各种复杂的解释reflog 就是一份记录了“HEAD 指针每次移动轨迹”的日志。Git 中几乎所有操作都会改变 HEAD 引用比如 commit、reset、checkout、merge、rebase、cherry-pickreflog 会把这些动作以及动作前后的 commit 哈希记下来。所以哪怕你执行了git reset --hard 某个旧的commit让分支指针一下子退回到以前那些后来提交的 commit 也不会立刻销毁——它们还悬在对象库里只是没有分支引用了。只要 reflog 里还留着它们的位置就能捞回来。看 reflog 的方式git reflog输出大致长这样a1b2c3d HEAD{0}: reset: moving to a1b2c3d f9e8d7c HEAD{1}: commit: feat: 完成登录模块这时你想回到f9e8d7c直接git reset --hard f9e8d7c或者创建一个新分支指向它git branch recover-branch f9e8d7c这个操作其实是在对象库里重新建立一个引用把那次提交从“无主”状态变成“有主”状态。5.2 reset --hard 之后的回血流程很多人对reset --hard有心理阴影觉得一旦执行就彻底完了。其实只要 reflog 还在就有救。我建议每个人都掌握下面这套回血流程关键时刻能救命。先别慌立刻执行git reflog。找到误操作前的那个哈希值也就是 reset 之前 HEAD 所在的位置。执行git reset --hard 那个哈希把分支引到原来的提交上。如果原来的分支基于别的提交或者不确定哈希是否准确可以先用git branch temp 哈希创建一个临时分支确认内容无误后再删除原分支并重命名。这里要特别提醒如果误操作之后你又执行了大量提交、变基、清理等操作reflog 里记录可能还在但有些对象可能已经被git gc清理掉了。所以越早发现、越早恢复成功率越高。最怕的是搞完之后又做了几十个操作最后才想起来要找原来的提交虽然 reflog 里可能还在但也增加了复杂度。5.3 reflog 的过期时间与 GCGit 的 reflog 并不是永久保留的。Git 有一个关于 reflog 过期时间的默认配置“失去引用的提交”默认保留 90 天。“仍然有引用的提交”默认保留 30 天。如果仓库里执行了git gc有时某些 GUI 工具会自动触发那些超过保留期且没有任何引用指向的对象可能会被真正删除。所以如果你意识到某个提交丢了越早捞越安全。另外reflog 只记录本地仓库的操作。如果你误操作的对象是从远程 clone 下来后本地做过的改动但远程仓库里从来没有过那远程无法帮你恢复只能靠本地 reflog。这也是为什么重要分支要常推送的原因之一。5.4 高级组合技reflog 配合 cherry-pick 找回“消失的改动”有一个我很常用的高级技巧有时候本地分支的某些提交被 reset 清掉了但另一条分支上需要这些改动。与其费劲去 reflog 翻找不如配合 cherry-pick 实现精准“移植”。假设 reflog 里看到abc1234 commit: 修复订单模块的 bug但当前分支已经 reset 到了别的提交你想把这次修复的改动移到当前分支。执行git cherry-pick abc1234Git 会尝试将abc1234这个提交的 diff 应用到当前分支上并生成一个新的提交。这样做的好处是不需要整个分支回到过去也不会把那次提交之后的无关改动带过来非常适合处理“只是想把某一次修复捞回来”的场景。不过 cherry-pick 遇到冲突也很常见解决方式和平常 merge 冲突类似处理完后git cherry-pick --continue完成这次操作如果不想继续了用git cherry-pick --abort退出。6. 提交规范与工程实践如何从源头减少误操作急救的东西讲得再多也不如让误操作发生的概率降到最低。这一节讲点偏工程实践的内容很多人可能觉得“提交规范”跟误操作急救没关系但我可以负责任地说很多事故都是因为提交不规范、commit message 不清、功能改动太大导致的。6.1 提交规范为什么能救命“规范”这个词听起来像是流程约束实际上它最大的作用是让每一个提交小到可以被理解、被定位、被回滚。如果一个提交只做一件事比如“修复登录页按钮样式”那么它出问题时你只需要 revert 或 cherry-pick 这一粒提交不会牵连其他功能。如果每个提交动辄几百行代码横跨多个模块而且 message 写的是“update”那一旦需要回退就无从下手只能靠猜。所以提交规范的第一个价值是“可回退性”这是急救的基础。第二个价值是“可读性”review 代码时能迅速知道每次改动在做什么误操作时也能快速定位往哪个提交返。6.2 经典提交格式与常用前缀业界最通用的提交规范是 Conventional Commits也就是“约定式提交”。它的核心格式是type[optional scope]: description常见的 type 有type含义feat新增功能fix修复 bugdocs文档变更style格式或样式调整不影响逻辑refactor重构不新增功能也不修 bugperf性能优化test测试相关chore构建工具、依赖等杂项举个例子feat: 新增用户注册接口 fix(login): 修复登录时 token 过期不刷新的问题 docs: 更新 README 部署说明在热词里看到“git提交规范”高居前列说明越来越多团队开始注意这个问题。我建议小团队不必一开始就上全套工具链先把 type 约定好强制大家按这个格式写 message就已经能得到很大收益。6.3 用工具守规矩husky commitlint如果团队想用工具来约束提交信息可以引入 husky 和 commitlint。husky 的作用是在 Git 钩子阶段比如 pre-commit、commit-msg执行一些检查commitlint 负责验证提交信息是否符合规范。简单配置思路是初始化 package.json安装 huskynpm install husky --save-dev npx husky install安装 commitlintnpm install commitlint/cli commitlint/config-conventional --save-dev创建.commitlintrc.json{ extends: [commitlint/config-conventional] }新增 commit-msg 钩子npx husky add .husky/commit-msg npx --no-install commitlint --edit $1这样当开发者提交时commitlint 会检查 message 格式。不合规的直接拦截强制让每个人按约定提交。另外还可以配合 lint-staged 做 pre-commit 的代码检查只对暂存区的文件运行 ESLint 或 Prettier避免全量检查太慢的问题。这类工具链本质上是在“提交前”就把风险止住。6.4 IDE 里 Git 命令参数背后是什么在使用 WebStorm、IDEA 这类 IDE 时打开 Git 控制台的日志经常会看到类似这样的命令git -c diff.mnemonicprefixfalse -c core.quotepathfalse --no-optional-locks status -sb很多人看不懂这些参数是什么其实它们是为了让 IDE 获得稳定的输出格式。-c diff.mnemonicprefixfalse是禁用 diff 前缀的简写模式-c core.quotepathfalse是让 Git 不对非 ASCII 文件名做转义避免中文文件名显示成大串\xxx编码--no-optional-locks是避免某些命令在后台获取可选锁防止 IDE 频繁操作时产生不必要的锁冲突。理解这些参数对解决“为什么终端里 Git 正常、IDE 里 Git 报错”很有帮助。比如中文文件名显示乱码一般就是core.quotepath的值问题IDE 操作时提示文件被锁定可能就和锁竞争有关。7. Git 疑难杂症速查表这一节做一个汇总把前面涉及到的和没细讲但同样高发的报错按“症状—原因—解法”整理成表格方便你“见症查方”。网上那些搜索热词大多数都能在这里找到对应的处理方向。报错或现象常见原因快速解法git 不是内部或外部命令PATH 未配置或安装不完整手动添加 PATH 或重装并勾选推荐项git 无法识别 cmdlet 报错Windows PowerShell 环境变量未刷新重新打开终端或配置 PATHunable to access / error setting certificate fileCA 证书路径失效或代理干扰修正 sslCAInfo必要时移除 http.proxyfatal: not a git repository当前不在仓库目录或 .git 丢失切到仓库根目录必要时 git initmerge 冲突后想放弃合并过程中断留下冲突标记git merge --abort误删分支分支引用被删除git reflog 找哈希git branch 恢复push 被拒绝non-fast-forward本地落后于远程或历史被改写先 pull 再 push或确认是否需要 force pushlogin failed. check api token or gitlab versionIDE 插件 Token 失效或版本不兼容重新生成 Token检查 GitLab 版本中文文件名显示异常core.quotepath 默认转义git config --global core.quotepath falseclone 一直卡住或超时网络代理或 DNS 问题检查 http.proxy、环境变量代理测试网络连通性提交信息写错commit message 有笔误git commit --amend -m 新信息误 add 了不想提交的文件暂存区放入了多余文件git restore --staged想放弃工作区全部改动改乱了一个或多个文件git restore . 或 git checkout -- .某次提交的改动丢了分支被 reset 或 rebase 丢提交git reflog 找哈希cherry-pick 或 reset 恢复git set proxy 后所有远程操作异常代理配置残留或代理不可用unset http.proxy / https.proxy清除环境变量这张表不能覆盖所有场景但覆盖了绝大多数人日常会遇到的“报错 10 秒内想不起解法”的情况。建议收藏起来以后遇到类似的问题先查一遍别一上来就百度复制粘贴命令。8. 大家容易忽视的几个操作习惯最后这块既不算命令详解也不算报错排查但我觉得对“守住代码生命线”这个目标来说比很多具体命令都重要。这些年我看过太多事故事后复盘时发现几乎都能追溯到某一个操作习惯的问题上。8.1 小步提交比什么都管用很多人习惯“改一天提交一次”甚至“改一周提交一次”。这种做法最危险的地方在于一旦需要回退你根本没有颗粒度合适的提交可供回退。一个提交里混合了三个功能、两个 bugfix、一次重构回退哪一个都不合适。小步提交的意思是一个逻辑单元一次提交。哪怕一天提交五六次完全没问题。提交信息写得清楚每次 diff 控制在几十到一两百行这才是健康的状态。这样即便误操作影响面也可控。这是从源头减少急救需求的最有效手段。8.2 push 前先看 diff我用过一个对自己很管用的习惯commit 之前一定执行git diff --cached看一遍暂存区的内容push 之前再执行git diff origin/master...HEAD看一遍本地新增的提交。这两步看似浪费时间实际上能在代码进入公共分支之前拦截掉大量低级问题。比如把密钥文件提交上去、把本地配置覆盖掉线上配置、多 add 了一个不该提交的文件这些问题在 diff 阶段一眼就能看到。8.3 不要轻易 force pushgit push --force是近些年来破坏协作仓库的头号杀手。Force push 直接把远程分支的历史覆盖成本地的样子别人基于旧历史的提交会直接“消失”在远程虽然本地可能还有。如果非要强制推送先确认这几点这个分支只有你一个人在用或者大家提前沟通过。你清楚地知道被覆盖的远程提交里没有别人有价值的工作。团队有备份分支或者你已经把旧的远程分支保存到了本地。哪怕满足了这些条件我也更建议用--force-with-lease替代--force。--force-with-lease在推送前会检查远程分支是否是你上次拉取的状态如果不是则拒绝推送这个机制能防止你把别人刚推上去的提交覆盖掉。8.4 给重要分支提前打好备份这里说的备份不是复制粘贴一个目录而是在 Git 层面建立一个或多个“保护性引用”。比如你准备在一个分支上做大的 rebase 或 reset先记录一下当前的位置git branch backup/feature-branch-20240101这个操作只是创建一个指向当前提交的新分支引用成本几乎为零但给了你一个明确的后悔药入口。同理在执行git filter-repo、大范围git rebase之前也都建议这么做。别嫌麻烦真到了需要回退的那天你会感激这个操作的。9. 写在最后像操作数据库一样敬畏 Git我见过有人反复强调“Git 很安全只要不 rm -rf .git”这句话大方向没错但它容易给人一种错觉反正怎么折腾都能恢复。实际上 Git 的安全性是有条件的——你必须理解 reflog 的机制、GC 的时机、远程与本地的关系并且在操作的第一时间就知道自己做了什么。一旦你盲目执行命令或者在一知半解的状态下用了reset --hard、force push甚至删除.git目录那风险依然真实存在。按照我个人的习惯每次动手操作 Git 之前我都会下意识地看一眼当前分支、当前状态确认要执行的操作会改变哪些东西。这个动作不需要额外成本但能避免很多没必要的急救。就像老司机点火前看三块后视镜一样多看一眼不耽误事但能让你少走很多弯路。这篇文章里涉及的命令除了极少数特例外都是我在日常开发里实际用过的。如果你能把 reflog 的用法和revert与reset的选型逻辑真正理解到位那恭喜你你已经比一大批“CtrlC/CtrlV 命令行”的开发人员强了。后续如果你遇到特别奇怪的 Git 异常也可以带着报错信息去 Git 官方文档或 Stack Overflow 上查一查很多问题并不是你一个人遇到过答案早就在那里。守住代码生命线这件事功夫在平时而不只是在事故发生的那几分钟里。