“Git 基础命令与核心概念”这东西我前后给不同团队的人讲过不下十遍每次讲完都有人回头问同一批问题为什么 add 了还要 commit、为什么切分支能瞬间完成、为什么 reset 之后本地文件也跟着变了。说到底不是命令记不住是脑子里那张图没画对。Git 的命令列表拉出来一百多个日常真正高频的不到二十个剩下的基本是在这二十个上换参数。所以这篇我不打算按字典顺序罗列命令而是按“先立模型、再拆命令、最后复盘故障现场”的顺序写把这二十来个命令为什么这么设计、什么时候该用哪个、用错了怎么救一次讲透。适合刚接触版本控制的新人也适合用了两三年但一直靠“复制粘贴同事的命令”过日子的朋友。全程只讲本地实操跟着敲就能复现。1. 先把心智模型立起来Git 到底在管什么很多人学 Git 卡住根子在于把它当成了“带历史记录的网盘”。网盘的心智模型是“文件被覆盖了就是覆盖了历史靠额外备份”而 Git 的心智模型是“每一次提交都是整个项目的一份完整快照历史是一条由快照串起来的链”。这两种模型在遇到“我想回到昨天下午的状态”时行为完全不一样。前者你要去找备份后者你只需要一个哈希值。所以学命令之前先把快照这个念头钉在脑子里后面所有命令的行为都能推导出来。1.1 三个区域与一次提交的完整旅程Git 把项目状态拆成三个区域工作区、暂存区、版本库。工作区就是你用编辑器打开、能看见的那堆文件版本库是.git目录里那套压缩过的对象数据库中间夹着的暂存区也叫索引index是一个二进制文件.git/index它记录的是“下一次提交要包含哪些内容”。这个中间层是新手最不适应的地方但也是最值钱的设计因为它让你能精细挑选“这次提交到底装哪几个改动”。用超市场景类比一下就很清楚工作区是货架你随手把东西放进购物车这一步叫git add购物车就是暂存区你可以反复往里放、往外拿货架上的东西不受影响git commit是结账购物车里的东西被打成一张小票存进账本这张小票就是一次提交。关键点在于结账只结购物车里的东西货架上还有一堆没放进车里的商品它们不会进这次小票。这就是为什么你改了两个文件只 add 了一个commit 之后另一个改动还在工作区躺着。一次完整的提交流程大概是这样改文件 →git status看谁变了 →git diff看具体变了什么 →git add挑要提交的部分 →git diff --staged复核一遍即将进入提交的内容 →git commit→git log确认。中间那两个 diff 是我强烈建议保留的习惯因为 add 之后再看一遍暂存区内容能拦住绝大多数“把调试代码一起提交上去”的事故。这一步多花十秒能省掉后面 revert 一次提交的十分钟。还有一点容易被忽略暂存区不是“临时缓存”它是有实际内容的git add之后文件内容就被写进对象库了只是还没有被某次提交引用。理解这一点后面讲git reset的三种模式时就不会觉得莫名其妙——重置的本质就是“移动分支指针”加“要不要顺带改暂存区和工作区”而不是“删除数据”。1.2 快照而非差异理解 Git 的存储方式绝大多数人以为 Git 存的是“每次改动的差异”实际上 Git 存的是快照差异是显示的时候现算的。.git/objects下面存着三类对象blob 存文件内容tree 存目录结构和文件名到 blob 的映射commit 存一个指向 tree 的指针加上父提交、作者、时间、提交信息。每次提交Git 会把当前所有被跟踪文件的内容算一遍哈希内容没变的文件直接复用已有的 blob 对象只有内容变了的才写入新对象。所以“每次提交存整个项目”听起来很浪费实际因为有内容寻址去重增量开销非常小。内容寻址这个机制值得多说两句。Git 对对象内容做 SHA-1 计算新版本也支持 SHA-256得到的四十位十六进制串就是对象名。这意味着两件事第一同样内容的文件在仓库里只存一份哪怕你有一百个文件内容完全相同第二任何对历史的篡改都会导致哈希对不上这是 Git 天然具备完整性的原因。你平时看到的a1b2c3d这种短哈希就是四十位哈希的前缀缩写只要在仓库里不冲突Git 允许你用前七位甚至更短来指代一个提交。这个模型解释了一个常见困惑为什么git checkout一个旧提交之后文件内容立刻变成了那个版本因为那个提交指向一棵完整的 tree切换就是把这棵树的内容铺到工作区。反过来说为什么删除一个分支不会丢数据因为分支只是个指针只要提交对象还在被别的东西引用着它就不会被回收。理解了对象之间的关系git gc、git fsck、git cat-file这些平时用不上的命令也就有了意义——它们是直接跟对象层打交道的工具。1.3 分支只是一个指针为什么建分支这么快如果你之前用过别的版本控制工具可能习惯了“建分支等于复制一份完整代码目录”那操作又慢又占空间所以大家都不爱建分支。Git 的分支完全是另一个东西refs/heads/目录下一个以分支名命名的文本文件里面就存一个四十位的提交哈希。仅此而已。创建一个分支就是新建一个文件写一行哈希耗时微秒级切换分支就是把 HEAD 指向这个文件然后把工作区内容换成对应快照。所以 Git 鼓励“一个功能一个分支用完就删”这个工作流在别的工具里是奢侈在 Git 里是默认。HEAD是个特殊引用它通常不直接指向某个提交而是指向某个分支比如refs/heads/main这叫“HEAD 附着在分支上”。你在提交时Git 先读 HEAD 找到当前分支然后把新提交的哈希写进那个分支文件。这就是为什么提交之后当前分支会自动往前走一步。如果 HEAD 直接指向某个提交而不是分支那就进入了所谓“分离头指针”状态这时候提交不会推进任何分支切走之后那些提交就只能靠哈希或 reflog 找回。这个状态不是错误但新手容易在里面迷路。还有一个推论因为分支只是指针所以“合并两个分支”本质上是在找一个能把两条历史接起来的提交然后把当前分支指针移过去。快进合并之所以快就是因为不需要造新提交直接把指针往前挪就行三方合并之所以要造新提交是因为两条历史分叉了需要一个新的提交同时把两个父提交都记下来。后面讲 merge 和 rebase 的区别其实就是在这个模型上做不同的指针操作没有魔法。2. 上手前的配置与本地仓库初始化装完 Git 之后第一件事不是敲命令是把身份配好否则提交记录里的作者信息会是一串奇怪的默认值等项目做大了想批量纠正作者信息会非常麻烦。配置分三层--system影响整台机器--global影响当前用户仓库内不带参数只影响当前仓库。层级越低优先级越高仓库级配置会覆盖全局配置。这个层级设计在多账号场景下很有用比如某个仓库你要用工作邮箱提交就在那个仓库里单独设一次user.email。2.1 必配的三项身份信息与换行符策略最基础的是用户名和邮箱这两个会被写进每一次提交是追溯“这行代码谁写的”的唯一依据所以别随便填个测试字符串。邮箱建议填真实可用的因为很多协作平台靠它把提交和账号关联起来。除此之外我会额外配三项默认分支名、编辑器、中文路径显示。默认分支名现在一般设成main避免每次 init 之后还要手动改名编辑器设成自己顺手的否则遇到要写多行提交信息或者交互式 rebase 时会跳进一个不熟悉的界面里出不来core.quotepath设成false否则中文文件名在git status里会显示成一串八进制转义看着就头大。git config --global user.name 你的名字 git config --global user.email youexample.com git config --global init.defaultBranch main git config --global core.editor vim git config --global core.quotepath false跨系统协作时换行符是个绕不过去的坑。Windows 用 CRLF类 Unix 系统用 LF同一个文件在不同系统上编辑就会被 Git 判定为“整个文件都改了”diff 一片红。处理策略有三种不管、全部转成 LF 存进仓库、或者在仓库里放一个.gitattributes明确指定。我的选择是第三种在仓库根目录放一个.gitattributes把文本文件统一声明成存储用 LF检出时按平台处理这样不管谁在什么系统上 clonediff 都是干净的。全局的core.autocrlf设置虽然也能用但它是每个开发者各自设的管不住别人团队协作还是靠仓库里的配置文件最靠谱。# 仓库根目录 .gitattributes * textauto eollf *.png binary *.jpg binary提示core.autocrlftrue在 Windows 上会把检出内容转成 CRLF、提交时转回 LF如果你的项目里有大量脚本文件比如 shell 脚本转换后可能因为\r导致脚本执行报错。遇到这种玄学问题先查换行符。2.2 git init 与 git clone 的取舍创建仓库只有两条路git init从零开始或者git clone从已有仓库复制一份。这两者的区别不只是“有没有远程”更关键的是 clone 会自动帮你配好远程地址和跟踪分支init 则是一个纯本地的空仓库需要你手动git remote add挂上去。新手常见错误是在一个已经有代码的目录里直接 clone 另一个仓库结果目录套目录最后提交了一个包含.git子目录的诡异结构别人拉下来直接炸。如果你手上已经有一堆代码想纳入版本管理正确的顺序是先在项目目录里git init然后写.gitignore再git add最后git commit。写.gitignore一定要在第一次 add 之前因为一旦某个文件被跟踪了之后再往.gitignore里加它是不生效的Git 会继续跟踪它。这个顺序问题坑过太多人尤其是那种node_modules已经被提交上去、仓库体积暴涨到几百兆的项目清理起来要动用历史重写工具代价很大。git clone的时候还有几个参数值得知道--depth 1做浅克隆只拉最近一次提交适合只看代码不需要历史的场景能省下大量时间和磁盘--branch指定克隆某个分支而不是默认分支--recurse-submodules在有子模块时一并初始化。浅克隆的代价是历史不完整git log看不到早期提交也没法直接做 merge 之类的操作需要时得用git fetch --unshallow补全。2.3 .gitignore 的匹配规则与常见坑.gitignore的规则说简单也简单说容易踩坑也真容易。基本语法是每行一个模式#开头是注释/结尾表示只匹配目录!开头表示取反排除。最容易搞错的是斜杠的位置build/会匹配任意层级的 build 目录/build/只匹配仓库根目录下的 buildbuild不带斜杠则文件和目录都匹配。另外*不跨目录**才跨目录doc/**/*.pdf这种写法才能匹配 doc 下面任意深度的 pdf。还有一个高频误区.gitignore只对未跟踪的文件生效。如果某个文件已经被git add过你后来把它写进忽略列表Git 依然会盯着它的改动。正确的处理方式是先用git rm --cached 文件名把它从索引里摘掉保留工作区文件再提交这次移除。如果是整个目录加-r参数。批量处理时可以先git ls-files列出所有被跟踪文件筛出该忽略的再批量摘除。# 把已被跟踪但应该忽略的文件从索引移除本地文件保留 git rm -r --cached node_modules git commit -m chore: 停止跟踪 node_modules注意git rm --cached之后如果不提交直接在别人那边 pull 下来的还是旧状态。另外团队协作时.gitignore本身是要提交进仓库的而个人编辑器配置比如某 IDE 的.idea目录建议放进.git/info/exclude那是本地私有的忽略列表不会污染团队仓库。3. 日常最常用的命令组合从改动到提交真正的日常操作其实就那几个命令来回组合熟练之后肌肉记忆比背文档管用。我把高频操作分成“看、挑、存、查”四类看是用 status 和 diff 搞清楚现状挑是用 add 决定这次提交装什么存是 commit 落盘查是 log 回溯。这四类里最容易被跳过的就是“看”很多人改完直接git add .然后 commit结果把临时文件、调试输出、注释掉的代码全带进去了。多看一眼的成本极低收益极高。3.1 status 与 diff先看清再动手git status是使用频率最高的命令没有之一。它输出的信息量比新手以为的大得多当前在哪个分支、有没有未跟踪文件、哪些改动已暂存、哪些还没暂存、本地分支和远程分支差几个提交、有没有正在进行的合并或 rebase 操作。养成每次动手前先敲一次的习惯能避免大量“我以为我在 main 分支上”的惨剧。输出太长的时候用git status -s看精简版两列状态码第一列是暂存区状态第二列是工作区状态看熟了比长格式还快。git diff有三个常用变体区别在于比较的两个端点不同。不带参数的git diff比较工作区和暂存区也就是“我改了但还没 add 的内容”git diff --staged或--cached比较暂存区和最后一次提交也就是“这次提交准备装进去的内容”git diff HEAD则是工作区直接对比最后一次提交把前两者合起来看。这三个变体搞混是新手最常见的困惑来源记住一句话就够了想看我刚改了什么用第一个想看这次提交会包含什么用第二个。git diff的输出格式也值得花两分钟看懂。开头的diff --git a/x b/x说明比较的是哪两个文件index那一行是两个 blob 的短哈希---和标出旧文件和新文件 -1,5 1,7 是块头表示旧文件从第 1 行开始的 5 行、新文件从第 1 行开始的 7 行后面的-是删除、是新增、空格开头是上下文。看懂块头对定位改动位置很有用尤其在 review 别人的补丁时。3.2 add 的三种粒度和交互式暂存git add看着简单其实有三种粒度。最粗的是git add .或git add -A把当前目录下所有改动一股脑塞进去快是快但容易误伤中等的是git add 文件名1 文件名2按文件挑最细的是git add -p按代码块挑。第三种是真正能把提交切干净的利器它会把你每个文件的改动拆成若干小块逐块问你“这段要不要进这次提交”回答可以是 y要、n不要、s拆得更细、e手工编辑、q退出。做代码 review 或者想把“重构”和“修 bug”拆成两个提交时全靠它。git add还有几个不常用但关键时刻救命的形式。git add -u只把已跟踪文件的修改和删除加入暂存区不会把新出现的未跟踪文件加进来适合“我不想漏掉任何改动但也不想把临时文件带进去”的场景。git add -i是交互式模式能做的事比-p更多包括查看未跟踪文件列表、选择性添加、取消暂存、查看差异界面朴素但功能完整。用惯了图形工具的人可能会觉得命令行交互丑但它的好处是任何环境都能用远程登录只带终端的时候照样干活。心得git add .在新版本 Git 里等价于git add -A .会把当前目录下的删除操作也记录下来但在很老的版本里.只是“新增和修改”不含删除。跨版本协作时如果发现删除的文件没被提交就是这个原因。3.3 commit 信息怎么写才不给未来挖坑提交信息这东西写的时候觉得无所谓半年后排查问题时它就是唯一的线索。行业里流传最广的写法是“一行标题 空行 正文”的结构标题控制在五十字符以内用祈使句描述“这次提交做了什么”比如“修复登录态过期后跳转失败”而不是“修复了一个 bug”正文说明“为什么改”而不是“改了什么”因为改了什么看 diff 就知道为什么改只有当时的你知道。这两者的区别在半年后看git log的时候会体现得淋漓尽致。如果需要按规范管理可以引入前缀约定比如feat:、fix:、docs:、refactor:、test:、chore:这几类。好处是能一眼从日志里区分改动性质配合工具还能自动生成变更日志。但别为了规范而规范提交粒度太碎、每个提交都只有一行fix: 修改那前缀也救不了。真正有价值的是“一个提交只做一件事”这样不管是二分查找定位问题、还是回滚某个功能都能精确命中不会出现“想回滚 A 功能结果把 B 功能也带走了”的尴尬。写多行提交信息时如果没配编辑器会直接进一个默认界面保存退出即可如果配了编辑器但中途想放弃把以#开头之外的所有行清空再保存Git 会认为这次提交无效并中止。这个机制在写了一半突然发现改错了文件时很有用不用 CtrlC 强行中断。另外git commit -m可以写多次每次一个-m之间会自动空行写“标题 正文”时比较方便。3.4 log 的几种实用过滤写法git log默认输出又长又啰嗦实际用起来必须加参数。--oneline把每个提交压成一行看历史脉络最直观--graph画出分支分叉的字符图合并历史一目了然-n 10只看最近十条--author名字按作者过滤--since2 weeks ago按时间过滤--grep关键词按提交信息搜-S 某段代码按内容变化搜这个最狠能找出“哪次提交引入或删除了这段字符串”。几个参数组合起来就是一套完整的考古工具。定位“某行代码是谁写的、哪次提交改的”用git blame 文件名比翻 log 高效得多它会在每行前面标出最后一次修改这行的提交哈希和作者。配合-L 起始行,结束行只看某个区间再配合-w忽略空白改动能把噪音降到最低。找到可疑提交之后再git show 哈希看完整改动这条链路是排查线上问题的标准动作。git log -p 文件名则是看单个文件的完整变更历史比 blame 更适合理解演进过程。还有一类场景是“我昨天明明提交了怎么找不到了”。这往往发生在分离头指针状态下的提交或者切分支前忘了合并。这时候git reflog是救命稻草它记录了 HEAD 的每一次移动包括切换、提交、重置、合并默认保留九十天。reflog 里的记录形如a1b2c3d HEAD{3}: commit: xxx找到目标哈希之后git branch 新分支名 哈希就能把它捞回来。这个命令我建议每个用 Git 的人都记住它救回来的工作可能是好几天。4. 分支、合并与变基协作里最容易出事的地方单打独斗的时候分支用得少一旦多人协作分支策略就是项目能不能顺畅推进的关键。原则只有一条主分支永远保持可发布状态任何未完成、未验证的东西都放在特性分支上。这条原则听起来简单实际执行时会遇到各种诱惑比如“就一个小改动直接在主分支上改吧”然后这个“小改动”引发了冲突主分支被卡在中间状态。分支的真正价值不是隔离代码而是隔离风险。4.1 branch / switch / checkout 的取舍git branch管分支的增删查改不带参数列出本地分支-a连远程分支一起列-v带上每个分支最后一次提交的摘要-d删除已合并的分支-D强制删除未合并的分支-m重命名。-d会在删除前检查这个分支是否已经合并进当前分支没合并会拒绝这是一道安全闸-D直接删删完只能靠 reflog 找回来。我一般先-d被拒绝了再想想到底该不该强删。切换分支早期都用git checkout 分支名但这个命令职责太杂既管切分支又管恢复文件容易误操作。新版本 Git 拆成了git switch和git restore两个命令切分支用switch恢复文件用restore语义清晰误操作的概率大幅下降。如果你装的版本支持2.23 以上我建议直接养成用新命令的习惯checkout留给那些还没升级的环境。切换时加-c可以“创建并切换”等价于先 branch 再 switch 两步合一。git switch main # 切到 main git switch -c feature-x # 创建并切到 feature-x git switch - # 切回上一个分支 git restore 文件名 # 丢弃工作区改动 git restore --staged 文件名 # 把文件从暂存区撤回工作区注意git restore丢弃工作区改动是不可逆的没提交的内容一旦丢了就只能重写。执行前先用git diff确认要丢的是什么或者干脆先git stash存一下留条后路。4.2 merge 的三种结果与冲突解决流程git merge会根据两个分支的历史关系产生三种结果。第一种是“已经是最新”目标分支的所有提交都已经在当前分支上什么都不做第二种是“快进合并”当前分支落后于目标分支且没有分叉Git 直接把指针往前挪不产生新提交第三种是“三方合并”两条历史分叉了Git 找到共同祖先把两边的改动合起来造一个新提交这个提交有两个父提交。想强制留下合并记录方便以后回溯“这个功能是什么时候合进来的”可以加--no-ff禁止快进。冲突只会发生在三方合并里而且只发生在“两边改了同一片区域”的时候。Git 没法判断谁对谁错就把两边的内容都塞进文件用、、标出边界等你手工裁决。解决流程是打开冲突文件把标记和不要的那部分删掉留下最终想要的内容然后git add标记为已解决所有冲突处理完再git commit收尾。中途想放弃这次合并git merge --abort能回到合并前的状态这个命令在处理一团乱麻的冲突时非常有用。冲突处理有个提高效率的技巧git checkout --ours 文件或--theirs 文件可以整体采用某一侧版本适合“这个文件我完全不要对方的改动”的场景git mergetool能调出图形化的三方对比工具左右各一侧、中间是结果比手工删标记直观得多。另外合并前先git fetch再git diff 当前分支 origin/目标分支看一眼差异范围心里有数之后处理冲突会快很多。4.3 rebase 的正确使用边界rebase 和 merge 的差别本质上是“历史怎么呈现”。merge 保留真实的分叉和合并记录历史像一张网rebase 把当前分支的提交一个个“摘下来、换个基点、重新贴上去”历史变成一条直线。直线的好处是git log干净、二分查找效率高坏处是提交哈希全变了等于重写了这段历史。所以有一条铁律已经推送到共享分支的提交不要 rebase。你自己本地还没推的提交随便 rebase 没人管一旦别人基于那些提交干活了你 rebase 再强推别人的历史就对不上了。日常最常用的是交互式 rebasegit rebase -i HEAD~3表示整理最近三次提交。弹出的列表里每个提交前面有个动作词pick保留reword改提交信息edit停下来修改内容squash合并到上一个提交并合并信息fixup合并但丢弃自己的信息drop删除。把几个零碎的“改个错别字”“再改一下”合成一个完整提交就是靠这个。操作时注意列表顺序是从旧到新跟git log相反刚开始容易看反。rebase 过程中遇到冲突解决完git add之后要用git rebase --continue继续而不是git commit。想中途放弃用git rebase --abort。还有一个高频误操作rebase 到一半发现搞错了直接关了终端仓库就卡在 rebase 中间状态后续所有命令都提示“你有一个 rebase 正在进行”。这时候同样是--abort收场。养成看git status第一行提示的习惯能避免在这种状态里瞎折腾。4.4 stash临时切换现场的应急手段正在写一个功能写到一半突然要切去修个紧急问题但当前改动还不适合提交——这是 stash 的典型场景。git stash会把工作区和暂存区的改动打包存起来工作区恢复到干净状态然后你安心切分支干活回来再git stash pop恢复。默认只存已跟踪文件的改动未跟踪的新文件不存要带上得加-u连忽略文件一起存用-a。存的时候加个说明git stash push -m 登录页改造半成品回头git stash list能看出哪个是哪个不然一堆WIP on main根本分不清。pop和apply的区别是pop恢复之后把这条 stash 删掉apply恢复但保留。恢复时有冲突的话pop不会删除记录处理完冲突手动git stash drop清理。stash 不是长期存储方案它没有分支结构、没有提交信息规范、也不跟着远程走存久了容易忘。我见过有人拿 stash 当“待办清单”用了半年最后 list 出来二十多条完全不知道哪条对应哪个需求。超过一天没处理的 stash建议转成正式分支。5. 撤销这件事reset、restore、revert 到底选哪个撤销是新手最慌的部分因为怕“一撤销就没了”。其实 Git 里绝大多数操作都可逆真正危险的只有一种改动从未被提交过然后被--hard或restore覆盖掉。只要提交过就有 reflog 兜底。把这句话记住操作时的心理负担会小很多。撤销命令的选择取决于三个问题要撤的是工作区改动、暂存区内容还是已经提交的历史撤完之后要不要保留改动内容这个提交有没有推给别人5.1 三棵树视角下 reset 的三种模式git reset有三个模式区别在于它影响到哪几棵树。Git 内部有个“三棵树”的说法HEAD最后一次提交、索引暂存区、工作区。--soft只移动 HEAD索引和工作区都不动效果是“撤销了提交但改动还在暂存区”适合“提交早了想再补点东西重新提交”--mixed是默认模式移动 HEAD 并重置索引工作区不动效果是“撤销提交和暂存改动回到工作区”适合“提交粒度太粗想拆成几个”--hard三个全动效果是“彻底回到那次提交的状态”工作区未提交的改动全部丢失这是唯一真正危险的模式。git reset --soft HEAD~1 # 撤销最近一次提交改动留在暂存区 git reset HEAD~1 # 等价于 --mixed改动回到工作区 git reset --hard HEAD~1 # 彻底回退工作区改动丢失 git reset --hard a1b2c3d # 回到指定提交用--hard之前有个习惯值得养成先git stash -u存一下当前状态再做重置万一发现回退过头了还能捞回来。另外git reset移动的是当前分支指针如果有未推送的提交被 reset 掉了用git reflog找到原哈希git reset --hard 原哈希就能回去。这个“reset 掉再用 reset 回来”的操作是新手最容易忽略的自救路径。5.2 revert 与 reset 的适用分界git reset是“把历史抹掉当那件事没发生过”git revert是“造一个新的提交把那次改动反向抵消掉”。前者改写历史后者追加历史。判断标准很明确提交已经推送到共享分支就只能用 revert。因为你 reset 之后本地历史跟远程不一致推上去要么被拒要么得强推强推会把别人的提交一起冲掉这是协作里的大忌。反过来纯本地的、还没推的提交用 reset 更干净历史里不会留下“引入又撤销”的痕迹。git revert 哈希会打开编辑器让你写撤销提交的信息保存后生成一个新提交。要撤销的是一个范围可以用git revert 旧哈希..新哈希注意这个范围是左开右闭不包含旧哈希本身。连续撤销多个提交时加--no-commit可以先把改动都堆在暂存区最后一次性提交避免生成一串“Revert xxx”的噪音提交。撤销合并提交时要加-m 1指定保留哪个父提交为主线这个参数容易忘忘了会直接报错提示。提示revert 一个合并提交撤销的是“这次合并带来的所有改动”包括合并进来那个分支上的所有提交。如果只想撤其中一部分revert 合并提交反而会把不相关的东西也撤掉这种情况得手工处理。5.3 误删分支与 reflog 兜底git branch -D删错分支是高频事故但只要提交对象还在就能救。git reflog列出 HEAD 的移动历史找到被删分支最后一次提交的哈希git branch 分支名 哈希就恢复了。如果记不清哈希可以git reflog --dateiso带时间看或者git log -g --all看所有引用的移动记录。reflog 默认保留九十天gc.reflogExpire可以调但我不建议调太短它是最后一道保险。比删分支更麻烦的是“提交了不该提交的东西”比如一个几百兆的压缩包或者含有密钥的配置文件。如果只是最近一次提交git rm --cached 文件再git commit --amend就能从这次提交里摘掉但如果已经推送到远程别人拉下去之后历史里还是有。彻底清理要用历史重写工具把那个文件从所有提交里抹掉操作复杂且影响所有协作者必须提前通知。所以真正的解法是预防.gitignore早早写好提交前看一眼git status的待提交列表。还有一种情况是“改崩了想回到某个已知好状态”。如果那个状态有对应提交git reset --hard 那个哈希就行如果没有但之前 stash 过git stash list找出来 apply如果都没有只能靠编辑器的本地历史和自己的记忆了。这也是为什么我建议重要节点一定提交一次哪怕提交信息写得潦草有个还原点比什么都强。6. 与远程仓库打交道fetch、pull、push 的细节远程操作的核心概念是“远程跟踪分支”它是本地对远程分支状态的只读快照命名形如origin/main。注意它不是一个真实存在的分支你不能切到它上面干活它只是一个书签记录“我上次跟远程通信时那边的 main 指向哪个提交”。git fetch做的事就是更新这些书签把远程新增的对象拉到本地但不动你的工作区和本地分支。理解了这一点pull和push的行为就都好解释了。6.1 跟踪分支与 upstream 设置本地分支和远程分支之间可以建立“跟踪关系”建立之后git pull和git push不带参数就知道该操作哪个远程分支git status也会告诉你“领先远程 2 个提交、落后 1 个提交”。新建本地分支时用git switch -c 分支名 origin/分支名会自动建立跟踪已经存在的分支用git branch -u origin/分支名补设。查看跟踪关系用git branch -vv输出里方括号中的内容就是 upstream 信息。git push -u origin 分支名是第一次推送时的常用写法-u就是顺手把 upstream 设好之后直接git push即可。如果推的时候提示“当前分支没有上游分支”要么是忘了-u要么是本地分支名和远程不一致。新版 Git 还有个push.autoSetupRemote配置设成 true 之后第一次 push 会自动建立跟踪省掉-u。6.2 pull 到底是 fetchmerge 还是 fetchrebasegit pull本质上是git fetch加上一个合并动作合并方式由配置决定。默认是 merge会在历史里留下合并提交配了pull.rebasetrue就变成 fetch rebase历史保持直线。两种都行关键是团队统一否则同一个仓库里一半人是网状历史一半人是直线git log --graph看着像乱码。我个人偏好 rebase因为拉取时产生的那些“Merge branch main of ...”提交实在没什么信息量但如果是多人频繁往同一分支推送的项目merge 更安全不会因为 rebase 反复改写本地提交。git pull --ff-only是我推荐给新手的写法它只在能快进的时候才合并一旦本地有分叉直接报错逼你先看清楚状况再决定 merge 还是 rebase。这个参数能挡掉大量“一拉取就产生一堆莫名其妙的合并提交”的情况。想更保险一点可以完全不用 pull改成git fetch之后先git log HEAD..origin/main --oneline看看远程多了什么再决定怎么合。多敲一个命令少一次手忙脚乱。6.3 强推的风险与 --force-with-leasegit push --force会用本地历史覆盖远程如果别人在这期间往同一分支推了提交那些提交就被抹掉了。这个操作在团队协作里基本等于“删库”除非你百分之百确定这个分支只有你在用。相对安全的替代是--force-with-lease它会在强推前检查远程分支是否还停留在你上次 fetch 时的位置如果别人推过东西它会拒绝这次强推。这个检查不能完全避免事故比如你刚 fetch 完别人就推了但能挡住绝大多数“忘了先拉一下”的情况。真正需要强推的场景其实很少基本只有两种rebase 了本地未共享的提交之后同步到自己的远程特性分支或者修正提交信息后重新推。主分支、发布分支这类共享分支应该配置保护规则禁止强推从机制上堵死。如果团队里有人习惯性push -f那迟早要出一次事故不如早点把习惯改成--force-with-lease并且在推之前git fetch一次。7. 常见问题与排查速查表Git 报错信息大多写得挺清楚只是英文加上专业术语新手容易一看就慌。我的经验是报错第一行通常就说明了问题类型后面几行是建议操作。遇到报错先别急着搜把git status敲一遍它输出的提示往往直接告诉你下一步该敲什么命令。下面这些是我这些年被问得最多、自己也踩过的场景整理成表方便对照。7.1 高频故障现场复盘场景一切换分支时提示“你的本地改动会被覆盖”。原因是你改的文件在两个分支上内容不同Git 不敢帮你覆盖。三条路提交改动、stash 存起来、或者git restore丢弃。选哪条取决于这些改动要不要留。千万别用-f强切那是直接丢改动。场景二推送到远程被拒提示 non-fast-forward。说明远程有你本地没有的提交。先git pull --rebase把远程的拉下来并把自己的提交接到后面解决可能的冲突再推。别一上来就--force那会覆盖别人的工作。场景三git status显示“HEAD detached at xxx”。你切到了某个提交而不是分支上。这时候的提交不属于任何分支切走就可能丢。想保留就git switch -c 新分支名建个分支接住不想保留直接切回原分支。场景四一个文件明明只改了一行diff 却整个文件都红了。八成是换行符问题Windows 和类 Unix 混用导致。检查.gitattributes或者临时用git diff --ignore-space-at-eol确认。根子上还是要统一换行符策略。场景五文件名大小写改了但 Git 没反应。某些文件系统不区分大小写Git 也默认忽略大小写变化。用git mv 旧名 新名显式改名或者临时git config core.ignorecase false。场景六合并之后发现合错了想撤回。如果还没推送git reset --hard HEAD~1回到合并前如果已经推送git revert -m 1 合并提交哈希造一个反向提交。后者更安全但要注意它会把整个分支的改动一起撤掉。7.2 一份可以直接收藏的排查表现象大概率原因处理方式提交作者信息是默认值没配 user.name / user.email补配后对最近一次提交用--amend --reset-author中文文件名显示成转义串core.quotepath为 truegit config --global core.quotepath false.gitignore里加了文件还是被跟踪文件已在索引中git rm --cached 文件名后提交拉取后多出一堆无意义的合并提交pull 用了 merge 模式改用git pull --rebase或配pull.rebase提交信息写错了手滑或遗漏最近一次用git commit --amend更早的用交互式 rebase误提交了大文件提交前没看 status未推送用--amend摘除已推送需历史重写删除分支后想找回分支指针没了但对象还在git reflog找哈希再git branch 名字 哈希冲突文件里全是尖括号标记三方合并需要人工裁决手工删标记留正确内容git add后继续stash 列表越积越多分不清存的时候没写说明用git stash push -m 说明定期清理克隆仓库特别慢历史太大git clone --depth 1浅克隆需要时再补全心得遇到完全看不懂的状态先做两件事——git status看当前处境git reflog看最近发生了什么。这两条命令合起来能还原百分之九十的“我刚才干了啥”比翻文档快得多。8. 我个人踩过的一些坑与习惯养成学 Git 最大的误区是想“先把所有命令学会再上手”。真实的路径是反过来的先用最少的命令把日常流程跑通遇到问题再针对性补。我最开始那阵子一个git checkout走天下切分支、丢改动、看旧版本全靠它也活了大半年。真正让水平上一个台阶的不是多背了几个命令而是把“暂存区”和“提交是快照”这两个概念想通了之后所有命令都是在这两个概念上做加减法看一眼参数就知道大概行为。有个习惯我坚持了很多年收益最大每次提交前必看git status和git diff --staged。前者确认有没有漏掉或多带文件后者确认暂存的内容是不是我想提交的。这两眼加起来不到十秒但能挡掉绝大部分“提交了调试代码”“提交了密钥”“提交了一半的改动”这类事故。刚开始会觉得啰嗦一个月之后就成本能了跟出门前摸一下口袋确认带没带钥匙一个性质。第二个习惯是给每个改动起个能被搜索到的提交信息。别写“update”“fix”“修改”写“修复订单列表分页参数越界”“补充登录接口的错误码说明”。半年后你搜git log --grep分页能一秒定位搜“修改”能出来两百条。这个投入产出比极高而且不需要任何额外工具纯粹是写的时候多敲十几个字的事。第三个习惯是拿不准的时候先 stash。不管是切分支、拉代码、试一个危险的重置操作先git stash -u存一份成本一条命令收益是“搞砸了还能回去”。stash 存太多会乱但作为一个临时保险它比任何“我记得我刚才改了什么”的自信都可靠。等你确认操作没问题再git stash drop清掉。最后一个建议是关掉那些一键提交的图形按钮。图形工具不是不能用但新手阶段用它会屏蔽掉“暂存区里到底装了什么”这个关键信息点两下就提交了出问题完全不知道从哪查。先在命令行里把 add、commit、status、diff、log 这几个跑熟理解每一步在做什么再换成图形工具那时候你用的是效率而不是黑箱。等你哪天在只有终端的环境里也能从容处理一个冲突就算是真正入门了。