1. 先聊聊为什么多数人被 Git 劝退我见过太多同事命令背得滚瓜烂熟每天无非就是git add .、git commit -m xxx、git push、git pull遇到冲突也能照着网上的脚本复制粘贴。但一旦仓库历史变复杂或者不小心reset错了地方整个人就懵了最后只能靠删掉整个目录重新 clone 来“解决问题”。这种状态说白了会用 Git但没理解 Git。本文想聊的不是再给你一份命令速查表而是把 Git 背后那套思维模型讲透。你一旦搞懂“对象”“指针”“三棵树”几乎所有命令都能自己推导出来遇到问题时也不会慌。适合刚接触 Git 的新手也适合已经写了两三年代码、但对 reset/rebase 这些命令始终绕不清楚的同学。1.1 界面操作掩盖了底层模型很多人在 Windows/Mac 上装完 Git再装一个带界面按钮的客户端点提交、点推送、点拉取一切都很顺畅。但 GUI 本质上把 Git 变成了一层“黑盒”你只看得到结果看不到仓库内部发生了什么。我并不是否认 GUI 的价值日常用 GUI 查历史、看差异也很爽。可问题是当你只有 GUI、没有底层模型时Git 遇到异常状态中断的 rebase、分离 HEAD、丢失的 commit你就没法应对了因为异常状态下界面本身也会被绕晕。而命令行虽然长得不好看但它暴露的是 Git 的真实结构从终端里看到的每一条提示、每一个引用都是仓库本身的样子。我建议至少在初期把主力操作切到命令行配合git log --graph、git status这类原生输出去感受每次操作后“仓库的结构”发生了什么变化。1.2 Git 的“保存点”和文件管理器的“保存”是两码事新手最常见的认知误区把git commit理解成“保存一下文件”。如果 Git 只是保存文件快照那它完全没必要设计暂存区、对象哈希、祖先链这一大堆复杂概念。Word 里的“保存”覆盖旧版本CtrlZ 可能撤销连续几步但 Git 完全不同Git 的每一次提交不是“覆盖”而是“新增一个永久对象”并且这个对象会记录它的父提交是谁。打个比方普通的保存像拍一张拍立得贴到相册里相册满了就把旧照片丢进垃圾桶Git 的提交像在一条时间线上加一个“密封舱”每个舱都标着“我在哪个时间点进来我继承自哪个舱”。旧舱不会因为你加了新舱而消失你随时可以回到任意一个舱内部。这个区别是所有后续理解的地基Git 是一个不可变的、带时间线的、有向无环图DAG。你可能听到过 DAG 这个词没关系后面我会用更具体的方式拆开它。2. Git 的对象模型一切的底层要理解 Git绕不开四个内部对象blob、tree、commit、tag。它们不常被初学者注意到但理解了它们你对“分支”“合并”“重置”的很多困惑会自动解开。2.1 blob、tree、commitGit 把“版本”拆成了什么直接看一个例子。你在项目里有一个src/main.js文件还有一个README.md。当你执行git add src/main.js时Git 并不会把文件原样丢进仓库而是做两步先对文件内容做一个哈希计算生成一个 40 位的十六进制字符串把内容按“blob 对象”的形式存进.git/objects里。blob 对象只关心“内容”不关心“文件名”。也就是说同一个内容哪怕在两个不同目录里它们对应的 blob 可能是同一个这能省不少空间。为什么要有 tree因为 blob 里没有文件名、没有目录层级。tree 对象就是“目录快照”它记录这个目录下有哪些文件名每个文件对应哪个 blob。文件夹套文件夹tree 套 tree最终形成一个树状结构。然后 commit 对象出现了。commit 里记录的东西包括指向某个 tree项目根目录快照、作者和提交者信息、时间、提交消息以及一个或多个父提交的哈希。所以下面这条命令git add README.md git commit -m add readme实际上发生的事情是先为README.md创建/复用了一个 blob更新了根目录的 tree让它指向新的“README.md 文件 - 对应 blob”关系创建了一个 commit 对象这个 commit 的编号是由 tree、父提交、作者、时间、消息一起算出来的。2.2 对象不可变与哈希寻址带来的好处一旦 commit 对象生成它就不会再变了。想改上一个提交不是“改”而是从那个提交派生出新提交原对象依然躺在仓库里只是没人引用它了。Git 会在适当时候通过垃圾回收把它清掉。这种“不可变 哈希寻址”的设计带来一个非常实际的好处你可以随时确认两个仓库是不是同一个状态——只要比较 HEAD 对应的哈希值就行。任何人拿到一个 commit 哈希就等于拿到了整个项目在该时刻的完整快照地址。Git 的分布式特性、断点传输、跨机器同步都建立在这个机制上。这里有一个我踩过很多次的坑很多人以为 git commit --amend 是“修改上次提交”其实它也是创建了一个新提交然后把分支指针移动到这个新提交上。旧提交在 reflog 里还能找到但平时你已经看不见它了。提示理解“对象不可变”后你会明白 Git 里的操作几乎都是在“加东西”或“移动指针”而不是在“改东西”。这个认知能帮你减少很多对误操作的恐惧。3. 三棵树工作区、暂存区、仓库Git 官方文档里有个经典说法一个 Git 仓库通常由“三棵树”组成。我强烈建议你把这三层装进脑子里。第一棵树工作区Working Directory就是你电脑里实际看到的文件。第二棵树暂存区Index / Staging Area你可以理解为“下一提交的候选区”。第三棵树本地仓库Repository / HEAD保存着所有历史提交。3.1 暂存区到底解决什么问题很多新手不理解为什么 Git 非要搞一个“暂存区”我提交的时候直接提交整个工作区不就好了吗答案是为了“精细控制提交内容”。比如你改了两个文件一个是修复 bug 的改动另一个是写了半截的新功能。你希望一次提交只承载一个逻辑单元此时就可以先把 bug 修复的文件add进暂存区提交一次新功能文件留到下次再提交。这种“分批提交”在团队协作里非常重要。因为代码评审Code Review是按提交来看的一个提交跨越多个无关主题会让评审者非常痛苦将来如果某个改动需要被回滚也会牵连不相关的改动。3.2 add、commit 在三棵树下是什么动作把“三棵树”作为坐标几个基础命令就变成动作描述了git add file把工作区中该文件的当前状态同步到暂存区git commit把暂存区的所有内容打包成一个 commit 对象让当前分支指针指向它git status对比三棵树之间的差异告诉我们“工作区和暂存区差在哪”“暂存区和仓库差在哪”git diff默认看工作区与暂存区的差异git diff --cached看暂存区与 HEAD 的差异。如果你理解了这张表就再也不会问“为什么我 commit 了但改动没进去”“为什么 git diff 看不到我刚改的内容”这类问题了。因为这些内容本质上是在问“我现在处在哪两棵树之间做对比”。注意git add之后又改了文件如果不重新addcommit 里包含的是旧版本不是最新版本。这是新手最容易犯的“漏提交”问题。4. 分支与 HEADGit 的“指针”世界观4.1 分支是指针不是文件夹很多用过 SVN 的人第一次看到 Git 分支会下意识认为分支是“代码的另一个副本文件夹”。这是对 Git 最大的误解之一。在 Git 里分支只是一个“可移动的指针”——指向某个 commit 对象。假设当前分支叫main它指向 commita1b2c3。当你在这个分支上提交了新的 commitd4e5f6main指针就会自动向前移动指向d4e5f6。那“多分支”是什么意思就是一棵 commit 树上多个名字分别钉在不同的 commit 上。这些分支共享绝大部分历史对象根本不会复制整份代码。你从main拉一个feature/x分支再在feature/x上提交main不会变但两条分支的“祖先链”是重叠的。创建一个分支的代价几乎为零git branch feature/logger git switch feature/logger它不过是在.git/refs/heads/下新增了一个文件里面写着一个 40 位哈希。理解了这一点你就不太会犯“分支开太多会不会很占空间”这种顾虑也不会在做多分支开发时在多个目录间反复复制代码。4.2 HEAD、HEAD^、HEAD~ 这些记号到底指什么HEAD 是另一个容易被忽略的概念。它不是分支而是“当前你身处哪个提交”的指针。通常 HEAD 指向某个分支名而分支名再指向具体 commit。所以说到底HEAD 是一个“指向指针的指针”。当你执行git switch main后HEAD 指向main这个名字当你在main上提交真正让main前进的是分支机制HEAD 只是跟着它走。另外要认识几个缩写HEAD当前提交HEAD~1当前提交的父提交往前一个HEAD~2往前两个HEAD^父提交和HEAD~1多数情况下等价HEAD^2合并提交的第二个父提交这些记号在历史操作、rebase、reset 里出现频率极高。举个例子你想看上一个提交改了哪些文件git show HEAD~1 git diff HEAD~1 HEAD能熟练写出这类命令说明你对“指针”已经有感觉了。很多人只敢git log往下看却不会在提交链上自由跳转其实本质上还是没绕过“提交是指针链”这个弯。4.3 游离 HEADdetached HEAD到底是什么状态再讲一个让很多人头皮发麻的状态HEAD detached at xxx。当 HEAD 不指向任何分支名而是直接指向一个 commit 哈希时Git 就进入“游离 HEAD”状态。比如你执行了git switch --detach HEAD~2或者直接git checkout 某个哈希。此时你处于一个“匿名分支”上。你在这个状态下提交新的 commit 就挂在历史链上但没有任何分支名指向它。等你切回别的分支这个新提交就会变得很难找到虽然 reflog 里还能捞回来。处理办法很简单要么新建分支来接住它——git switch -c temp-branch要么切回原分支放弃这个匿名提交。理解游离 HEAD 后你就知道“checkout 到哈希然后改了代码找不到提交”不是 Git 丢了东西而是你当时没有给它挂上一个名字。5. 真正理解 reset、checkout 和 revert这三个命令常被放在一起比较因为它们的字面意思都有“回退/切换”的味道。但底层逻辑完全不同。5.1 reset 的三种模式git reset做的事情可以概括为把当前分支指针移动到指定提交并且按模式决定是否重置暂存区和工作区。三个模式分别是--soft只移动分支指针暂存区和工作区都不动。--mixed默认移动分支指针重置暂存区但不动工作区。--hard移动分支指针重置暂存区同时重置工作区。用一个具体例子解释。假设当前在main上HEAD 指向 commit C你写了若干改动部分已addgit reset --soft HEAD~1执行后分支指针退到 C 的父提交但你之前add的那些内容还在暂存区工作区文件也没变。这适合“我刚才提交信息写错了/文件漏了想重新提交”的场景。而git reset --mixed HEAD~1执行后分支指针退一格暂存区被清空所有差异变成“已修改未暂存”状态。工作区文件依然是你最新的样子。这适合“我想撤销上次提交但保留所有改动重新整理后再次提交”。最危险的是git reset --hard HEAD~1它把分支指针、暂存区、工作区全部退回到上一个提交的内容。这意味着你在工作区里的所有未提交改动会一并被“打回原形”有可能会丢代码。我在工作里见过不止一个人因为手误敲了reset --hard而损失半天工作量。好在 Git 有 reflog可以捞回一部分但这绝对不是你应该依赖的手段。重要git reset只影响你的本地仓库。如果该分支已经被推送到了远端执行reset之后再push会颠覆远端历史通常需要用--force-with-lease才能推上去。这种操作在共享分支上要格外谨慎。5.2 checkout 与 revert 的定位git checkout的核心作用是“切换”本质是更新 HEAD 的指向并在需要时同步工作区文件。git checkout branch是切换分支git checkout file则是“把该文件恢复到 HEAD 或指定提交里的版本”。而git revert和它们都不一样。它不会移动分支指针而是创建一个“反向提交”来抵消目标提交的改动。比如你执行git revert a1b2c3Git 会对比a1b2c3这个提交的改动生成一个改动相反的 commit追加到当前分支上。历史记录里保留着“曾经有一个提交 a1b2c3”同时又多了一个“把它撤销掉”的提交。什么时候用 revert最常见的是在共享分支上撤销某个已经推送到远端的提交。因为它是一个新提交其他协作者直接pull就能同步不会造成历史撕裂。而 reset 更像“我后悔了假装这件事没发生过”适合用在还没有推送的本地提交上。我见过很多新手遇到“提交到远端后发现是个 bug”时直接reset --hard再强推搞得团队其他成员的历史一团乱麻。其实这时候更稳妥的做法多半是 revert。6. 理解 merge 与 rebase两条不同的路线分支的价值在于并行开发而如何把分支成果汇回主线就是 merge 与 rebase 的职责。两者的共同点是“把两个分支的改动合并到一起”但生成的提交历史形态截然不同。6.1 merge 的三方合并假设你在main上提交了 commit A从 A 拉出分支feature在feature上提交了 commit B、C。与此同时main上也被推送了 commit D。此时feature和main有了共同祖先 A但各自向前走了一段。执行git switch main git merge featureGit 会同时读取三个快照共同祖先 A、当前分支 main 的提交 D、待并入分支 feature 的提交 C。然后进行三方合并生成一个新的合并提交 M。M 有两个父提交分别是 D 和 C。这就是为什么git log --graph里会出现分叉和汇聚的线条。合并提交的存在让历史真实记录了“哪些内容是从不同分支汇进来的”。好处是完整、可追溯、不打乱原提交坏处是当多人长时间并行时历史图会变得非常密集可读性下降。merge 很容易出现冲突。冲突的根源是双方改了同一处内容Git 无法自动判断谁是对的。它会在文件里插入冲突标记 HEAD 这里是我本地的改动 这里是对方分支的改动 feature解决冲突后要git add标记为已解决然后继续 merge 或提交。如果你中途发现冲突太麻烦想撤销合并还没提交的话可以用git merge --abort回到合并前的状态。6.2 rebase 的“重放”机制rebase字面意思是“改变基准”。它做的事情是把你所在分支的提交一个个“摘下来”重新放到另一个提交的顶端。git switch feature git rebase main效果是把 feature 上基于 A 的 B、C 两个提交重新在 D 之后“重放”一遍。重放后的提交不再是原来的 B、C而是内容相同但父提交变成了 D 的新提交哈希也会改变。因此rebase 会重写提交历史。它带来的最大好处是历史线性化。合并后的git log是一条直线读起来像是 feature 的改动一个接一个叠在 main 之上特别适合偏向代码整洁、希望历史容易回溯的团队。但 rebase 有几个常见的坑不要 rebase 公共分支。如果别的同事已经从你的分支拉过代码并提交了东西你执行 rebase 会给别人带来“历史被重写”的灾难。rebase 冲突要按提交逐个解决。因为它相当于一次一次地重放冲突可能在一个提交里出现、在下一个提交里又出现处理的心智负担比 merge 更高。中断的 rebase 必须处理干净。如果你执行git rebase main时遇到冲突却走开了仓库会一直停留在“rebase 进行中”的中间态后续的所有操作都会受限。我用项目中的实际场景总结一下两者的选择逻辑场景推荐方式原因个人开发分支还没推送rebase保持整洁线性同步主线后再合并公共分支、多人协作分支merge 或详见团队规范避免重写他人依赖的历史只想把主线的 bugfix 带回自己的长期分支merge保留真实合并关系后续 rebase 更省心开 PR 前想整理提交信息交互式 rebasegit rebase -i可以合并、拆分、修改提交顺序和消息6.3 交互式 rebase整理提交的利器很多团队要求提交历史有清晰的结构不喜欢“fix typo”“add something”“oops”这类碎提交。交互式 rebase 就能派上用场。git rebase -i HEAD~3这会打开一个编辑界面展示最近 3 个提交的列表。你可以把pick改成squash把某个提交合并到前一个里也可以修改提交顺序甚至edit某个提交并重新改动。这里我要强调一件事交互式 rebase 不是让你硬造一个“从不犯错”的假历史而是让那条历史链中的每一次提交都有一个完整、可读的语义单元。对后来的维护者来说一条干净的历史比 20 个“wip”提交要有价值得多。7. 实操中的常见混战与排查心得理解再多的概念最终还是要落到每天面对的终端和代码里。这一节整理几个我实际工作中频繁遇到、也是新手最容易慌的场景。7.1 文件冲突不一定是你改错了第一次遇到合并冲突很多人会本能地觉得“是不是我把别人的代码弄坏了、要不要重新 clone”。其实冲突只是一个正常的“需要你决策”的信号。解决冲突的推荐顺序是确认当前在哪个分支、要合并哪个分支。git status会列出冲突文件逐个打开冲突文件搜索、、标记决定保留哪边、删除哪边还是做手动融合确认结果后git add file所有文件都解决后执行git merge --continue/git rebase --continue/ 直接git commit看处于哪种操作中最后在本地跑一次构建和测试确保解决冲突的过程没有引入新问题。我个人有个习惯冲突内容较多时不直接在编辑器的“采用当前/采用对方”按钮里快速选边。先用git diff把双方改动完整看一遍再打开一次全貌因为两个分支可能只是“各自改了同一个函数”但上下文已经完全不同只按按钮很可能丢掉语义。注意能自动合并的情况里也有隐患。比如一个分支改了某个函数实现另一个分支改了调用处注释Git 能合并但结果未必符合预期。合并不报错不代表逻辑正确合并完要多跑测试。7.2 误删、误提交、误 reset 的挽回现场先讲最“急救”的工具reflog。它是 Git 的本地日志记录了你每一次操作引起的 HEAD 变化。git reflog输出里会列出你最近做过的 reset、commit、checkout、merge 等操作以及操作前后的提交哈希。假设你误执行了git reset --hard HEAD~3发现刚才的三次提交不见了。打开 reflog找到 reset 之前 HEAD 指向的哈希然后执行git reset --hard 那个哈希就可以把分支指针拉回来工作区也会恢复到当时的状态。这是我自己恢复过不止一次“看起来丢了”的提交。另外如果你只是漏了某个文件没有提交但已经 commit别急着 reset。可以先git add 漏掉的文件 git commit --amend它会把你漏掉的文件补到上一个提交里生成一个新的提交替掉旧的。注意如果这个提交已经 push 到了远端--amend也会产生重写历史的效果需要谨慎一般只用于本地提交。还有个常见误场景想丢弃工作区某个文件的改动恢复成 HEAD 版本git restore file比git checkout -- file更贴近直觉老命令你偶尔也能在文档里看到但新项目用restore就好。反过来如果发现改错了想回到暂存区里的某个版本可以用git restore --staged file把文件从暂存区撤回工作区。7.3 日常协作里最值得养成的几个习惯代码写多了之后你会发现“理解 Git”不等于“把每个命令都记住”而是在团队合作里养成几个不会让彼此难受的习惯。第一提交之前先用git status和git diff自查一遍。我经常看到新人一股脑git add .把密码、构建产物、不该提交的临时文件全部塞进去了。git status能让你看见工作区里所有“未跟踪文件”特别是那些不认识的.log、.env文件。配合.gitignore可以把常见产物都提前挡在外面。第二提交信息要有语义。不是一个笼统的“update”而是简单描述“这段改动做了什么、为什么”。这样日后看git log或做代码评审时不需要一句句猜代码。第三遇到搞不定的仓库状态先别急着删目录。几乎所有的 90% 的 Git 问题都有一句通用的保命咒语git status和git reflog。它们会告诉你当前在哪、以及之前经过了哪里。删目录重来虽然最快但会让你错过学习和理解仓库结构的机会下次还是会在同一个坑里栽倒。第四推送前多确认一次。git push本身不可怕可怕的是加上了--force或--force-with-lease。我在本地演示分支上用强制推送已经习以为常但在共享分支上除非你有明确的团队纪律否则尽量避免。如果真的需要重写远端历史先和所有涉及到的同事同步选一个大家都不在拉取的窗口再操作。最后分享一个我自己的体会学 Git 不是背指令而是学“模型”。第一次看到别人用一条我没见过的命令时我不会急着抄而是先想想这条命令操作的是哪棵树移动的是哪个指针会影响谁一旦这样思考绝大部分命令都很容易归类。后面你遇到任何 Git 报错第一反应也不会是复制粘贴网上脚本而是先看git status再看报错提示里提到的具体文件和引用这一步做多了你会比用了一两年 GUI 工具的同事更稳。 
长河君 · 2026/10/20 12:07:14 · 阅读 1.2k Git核心机制详解：从对象模型到分支重置，彻底告别死记硬背
1. 先聊聊为什么多数人被 Git 劝退我见过太多同事命令背得滚瓜烂熟每天无非就是git add .、git commit -m xxx、git push、git pull遇到冲突也能照着网上的脚本复制粘贴。但一旦仓库历史变复杂或者不小心reset错了地方整个人就懵了最后只能靠删掉整个目录重新 clone 来“解决问题”。这种状态说白了会用 Git但没理解 Git。本文想聊的不是再给你一份命令速查表而是把 Git 背后那套思维模型讲透。你一旦搞懂“对象”“指针”“三棵树”几乎所有命令都能自己推导出来遇到问题时也不会慌。适合刚接触 Git 的新手也适合已经写了两三年代码、但对 reset/rebase 这些命令始终绕不清楚的同学。1.1 界面操作掩盖了底层模型很多人在 Windows/Mac 上装完 Git再装一个带界面按钮的客户端点提交、点推送、点拉取一切都很顺畅。但 GUI 本质上把 Git 变成了一层“黑盒”你只看得到结果看不到仓库内部发生了什么。我并不是否认 GUI 的价值日常用 GUI 查历史、看差异也很爽。可问题是当你只有 GUI、没有底层模型时Git 遇到异常状态中断的 rebase、分离 HEAD、丢失的 commit你就没法应对了因为异常状态下界面本身也会被绕晕。而命令行虽然长得不好看但它暴露的是 Git 的真实结构从终端里看到的每一条提示、每一个引用都是仓库本身的样子。我建议至少在初期把主力操作切到命令行配合git log --graph、git status这类原生输出去感受每次操作后“仓库的结构”发生了什么变化。1.2 Git 的“保存点”和文件管理器的“保存”是两码事新手最常见的认知误区把git commit理解成“保存一下文件”。如果 Git 只是保存文件快照那它完全没必要设计暂存区、对象哈希、祖先链这一大堆复杂概念。Word 里的“保存”覆盖旧版本CtrlZ 可能撤销连续几步但 Git 完全不同Git 的每一次提交不是“覆盖”而是“新增一个永久对象”并且这个对象会记录它的父提交是谁。打个比方普通的保存像拍一张拍立得贴到相册里相册满了就把旧照片丢进垃圾桶Git 的提交像在一条时间线上加一个“密封舱”每个舱都标着“我在哪个时间点进来我继承自哪个舱”。旧舱不会因为你加了新舱而消失你随时可以回到任意一个舱内部。这个区别是所有后续理解的地基Git 是一个不可变的、带时间线的、有向无环图DAG。你可能听到过 DAG 这个词没关系后面我会用更具体的方式拆开它。2. Git 的对象模型一切的底层要理解 Git绕不开四个内部对象blob、tree、commit、tag。它们不常被初学者注意到但理解了它们你对“分支”“合并”“重置”的很多困惑会自动解开。2.1 blob、tree、commitGit 把“版本”拆成了什么直接看一个例子。你在项目里有一个src/main.js文件还有一个README.md。当你执行git add src/main.js时Git 并不会把文件原样丢进仓库而是做两步先对文件内容做一个哈希计算生成一个 40 位的十六进制字符串把内容按“blob 对象”的形式存进.git/objects里。blob 对象只关心“内容”不关心“文件名”。也就是说同一个内容哪怕在两个不同目录里它们对应的 blob 可能是同一个这能省不少空间。为什么要有 tree因为 blob 里没有文件名、没有目录层级。tree 对象就是“目录快照”它记录这个目录下有哪些文件名每个文件对应哪个 blob。文件夹套文件夹tree 套 tree最终形成一个树状结构。然后 commit 对象出现了。commit 里记录的东西包括指向某个 tree项目根目录快照、作者和提交者信息、时间、提交消息以及一个或多个父提交的哈希。所以下面这条命令git add README.md git commit -m add readme实际上发生的事情是先为README.md创建/复用了一个 blob更新了根目录的 tree让它指向新的“README.md 文件 - 对应 blob”关系创建了一个 commit 对象这个 commit 的编号是由 tree、父提交、作者、时间、消息一起算出来的。2.2 对象不可变与哈希寻址带来的好处一旦 commit 对象生成它就不会再变了。想改上一个提交不是“改”而是从那个提交派生出新提交原对象依然躺在仓库里只是没人引用它了。Git 会在适当时候通过垃圾回收把它清掉。这种“不可变 哈希寻址”的设计带来一个非常实际的好处你可以随时确认两个仓库是不是同一个状态——只要比较 HEAD 对应的哈希值就行。任何人拿到一个 commit 哈希就等于拿到了整个项目在该时刻的完整快照地址。Git 的分布式特性、断点传输、跨机器同步都建立在这个机制上。这里有一个我踩过很多次的坑很多人以为 git commit --amend 是“修改上次提交”其实它也是创建了一个新提交然后把分支指针移动到这个新提交上。旧提交在 reflog 里还能找到但平时你已经看不见它了。提示理解“对象不可变”后你会明白 Git 里的操作几乎都是在“加东西”或“移动指针”而不是在“改东西”。这个认知能帮你减少很多对误操作的恐惧。3. 三棵树工作区、暂存区、仓库Git 官方文档里有个经典说法一个 Git 仓库通常由“三棵树”组成。我强烈建议你把这三层装进脑子里。第一棵树工作区Working Directory就是你电脑里实际看到的文件。第二棵树暂存区Index / Staging Area你可以理解为“下一提交的候选区”。第三棵树本地仓库Repository / HEAD保存着所有历史提交。3.1 暂存区到底解决什么问题很多新手不理解为什么 Git 非要搞一个“暂存区”我提交的时候直接提交整个工作区不就好了吗答案是为了“精细控制提交内容”。比如你改了两个文件一个是修复 bug 的改动另一个是写了半截的新功能。你希望一次提交只承载一个逻辑单元此时就可以先把 bug 修复的文件add进暂存区提交一次新功能文件留到下次再提交。这种“分批提交”在团队协作里非常重要。因为代码评审Code Review是按提交来看的一个提交跨越多个无关主题会让评审者非常痛苦将来如果某个改动需要被回滚也会牵连不相关的改动。3.2 add、commit 在三棵树下是什么动作把“三棵树”作为坐标几个基础命令就变成动作描述了git add file把工作区中该文件的当前状态同步到暂存区git commit把暂存区的所有内容打包成一个 commit 对象让当前分支指针指向它git status对比三棵树之间的差异告诉我们“工作区和暂存区差在哪”“暂存区和仓库差在哪”git diff默认看工作区与暂存区的差异git diff --cached看暂存区与 HEAD 的差异。如果你理解了这张表就再也不会问“为什么我 commit 了但改动没进去”“为什么 git diff 看不到我刚改的内容”这类问题了。因为这些内容本质上是在问“我现在处在哪两棵树之间做对比”。注意git add之后又改了文件如果不重新addcommit 里包含的是旧版本不是最新版本。这是新手最容易犯的“漏提交”问题。4. 分支与 HEADGit 的“指针”世界观4.1 分支是指针不是文件夹很多用过 SVN 的人第一次看到 Git 分支会下意识认为分支是“代码的另一个副本文件夹”。这是对 Git 最大的误解之一。在 Git 里分支只是一个“可移动的指针”——指向某个 commit 对象。假设当前分支叫main它指向 commita1b2c3。当你在这个分支上提交了新的 commitd4e5f6main指针就会自动向前移动指向d4e5f6。那“多分支”是什么意思就是一棵 commit 树上多个名字分别钉在不同的 commit 上。这些分支共享绝大部分历史对象根本不会复制整份代码。你从main拉一个feature/x分支再在feature/x上提交main不会变但两条分支的“祖先链”是重叠的。创建一个分支的代价几乎为零git branch feature/logger git switch feature/logger它不过是在.git/refs/heads/下新增了一个文件里面写着一个 40 位哈希。理解了这一点你就不太会犯“分支开太多会不会很占空间”这种顾虑也不会在做多分支开发时在多个目录间反复复制代码。4.2 HEAD、HEAD^、HEAD~ 这些记号到底指什么HEAD 是另一个容易被忽略的概念。它不是分支而是“当前你身处哪个提交”的指针。通常 HEAD 指向某个分支名而分支名再指向具体 commit。所以说到底HEAD 是一个“指向指针的指针”。当你执行git switch main后HEAD 指向main这个名字当你在main上提交真正让main前进的是分支机制HEAD 只是跟着它走。另外要认识几个缩写HEAD当前提交HEAD~1当前提交的父提交往前一个HEAD~2往前两个HEAD^父提交和HEAD~1多数情况下等价HEAD^2合并提交的第二个父提交这些记号在历史操作、rebase、reset 里出现频率极高。举个例子你想看上一个提交改了哪些文件git show HEAD~1 git diff HEAD~1 HEAD能熟练写出这类命令说明你对“指针”已经有感觉了。很多人只敢git log往下看却不会在提交链上自由跳转其实本质上还是没绕过“提交是指针链”这个弯。4.3 游离 HEADdetached HEAD到底是什么状态再讲一个让很多人头皮发麻的状态HEAD detached at xxx。当 HEAD 不指向任何分支名而是直接指向一个 commit 哈希时Git 就进入“游离 HEAD”状态。比如你执行了git switch --detach HEAD~2或者直接git checkout 某个哈希。此时你处于一个“匿名分支”上。你在这个状态下提交新的 commit 就挂在历史链上但没有任何分支名指向它。等你切回别的分支这个新提交就会变得很难找到虽然 reflog 里还能捞回来。处理办法很简单要么新建分支来接住它——git switch -c temp-branch要么切回原分支放弃这个匿名提交。理解游离 HEAD 后你就知道“checkout 到哈希然后改了代码找不到提交”不是 Git 丢了东西而是你当时没有给它挂上一个名字。5. 真正理解 reset、checkout 和 revert这三个命令常被放在一起比较因为它们的字面意思都有“回退/切换”的味道。但底层逻辑完全不同。5.1 reset 的三种模式git reset做的事情可以概括为把当前分支指针移动到指定提交并且按模式决定是否重置暂存区和工作区。三个模式分别是--soft只移动分支指针暂存区和工作区都不动。--mixed默认移动分支指针重置暂存区但不动工作区。--hard移动分支指针重置暂存区同时重置工作区。用一个具体例子解释。假设当前在main上HEAD 指向 commit C你写了若干改动部分已addgit reset --soft HEAD~1执行后分支指针退到 C 的父提交但你之前add的那些内容还在暂存区工作区文件也没变。这适合“我刚才提交信息写错了/文件漏了想重新提交”的场景。而git reset --mixed HEAD~1执行后分支指针退一格暂存区被清空所有差异变成“已修改未暂存”状态。工作区文件依然是你最新的样子。这适合“我想撤销上次提交但保留所有改动重新整理后再次提交”。最危险的是git reset --hard HEAD~1它把分支指针、暂存区、工作区全部退回到上一个提交的内容。这意味着你在工作区里的所有未提交改动会一并被“打回原形”有可能会丢代码。我在工作里见过不止一个人因为手误敲了reset --hard而损失半天工作量。好在 Git 有 reflog可以捞回一部分但这绝对不是你应该依赖的手段。重要git reset只影响你的本地仓库。如果该分支已经被推送到了远端执行reset之后再push会颠覆远端历史通常需要用--force-with-lease才能推上去。这种操作在共享分支上要格外谨慎。5.2 checkout 与 revert 的定位git checkout的核心作用是“切换”本质是更新 HEAD 的指向并在需要时同步工作区文件。git checkout branch是切换分支git checkout file则是“把该文件恢复到 HEAD 或指定提交里的版本”。而git revert和它们都不一样。它不会移动分支指针而是创建一个“反向提交”来抵消目标提交的改动。比如你执行git revert a1b2c3Git 会对比a1b2c3这个提交的改动生成一个改动相反的 commit追加到当前分支上。历史记录里保留着“曾经有一个提交 a1b2c3”同时又多了一个“把它撤销掉”的提交。什么时候用 revert最常见的是在共享分支上撤销某个已经推送到远端的提交。因为它是一个新提交其他协作者直接pull就能同步不会造成历史撕裂。而 reset 更像“我后悔了假装这件事没发生过”适合用在还没有推送的本地提交上。我见过很多新手遇到“提交到远端后发现是个 bug”时直接reset --hard再强推搞得团队其他成员的历史一团乱麻。其实这时候更稳妥的做法多半是 revert。6. 理解 merge 与 rebase两条不同的路线分支的价值在于并行开发而如何把分支成果汇回主线就是 merge 与 rebase 的职责。两者的共同点是“把两个分支的改动合并到一起”但生成的提交历史形态截然不同。6.1 merge 的三方合并假设你在main上提交了 commit A从 A 拉出分支feature在feature上提交了 commit B、C。与此同时main上也被推送了 commit D。此时feature和main有了共同祖先 A但各自向前走了一段。执行git switch main git merge featureGit 会同时读取三个快照共同祖先 A、当前分支 main 的提交 D、待并入分支 feature 的提交 C。然后进行三方合并生成一个新的合并提交 M。M 有两个父提交分别是 D 和 C。这就是为什么git log --graph里会出现分叉和汇聚的线条。合并提交的存在让历史真实记录了“哪些内容是从不同分支汇进来的”。好处是完整、可追溯、不打乱原提交坏处是当多人长时间并行时历史图会变得非常密集可读性下降。merge 很容易出现冲突。冲突的根源是双方改了同一处内容Git 无法自动判断谁是对的。它会在文件里插入冲突标记 HEAD 这里是我本地的改动 这里是对方分支的改动 feature解决冲突后要git add标记为已解决然后继续 merge 或提交。如果你中途发现冲突太麻烦想撤销合并还没提交的话可以用git merge --abort回到合并前的状态。6.2 rebase 的“重放”机制rebase字面意思是“改变基准”。它做的事情是把你所在分支的提交一个个“摘下来”重新放到另一个提交的顶端。git switch feature git rebase main效果是把 feature 上基于 A 的 B、C 两个提交重新在 D 之后“重放”一遍。重放后的提交不再是原来的 B、C而是内容相同但父提交变成了 D 的新提交哈希也会改变。因此rebase 会重写提交历史。它带来的最大好处是历史线性化。合并后的git log是一条直线读起来像是 feature 的改动一个接一个叠在 main 之上特别适合偏向代码整洁、希望历史容易回溯的团队。但 rebase 有几个常见的坑不要 rebase 公共分支。如果别的同事已经从你的分支拉过代码并提交了东西你执行 rebase 会给别人带来“历史被重写”的灾难。rebase 冲突要按提交逐个解决。因为它相当于一次一次地重放冲突可能在一个提交里出现、在下一个提交里又出现处理的心智负担比 merge 更高。中断的 rebase 必须处理干净。如果你执行git rebase main时遇到冲突却走开了仓库会一直停留在“rebase 进行中”的中间态后续的所有操作都会受限。我用项目中的实际场景总结一下两者的选择逻辑场景推荐方式原因个人开发分支还没推送rebase保持整洁线性同步主线后再合并公共分支、多人协作分支merge 或详见团队规范避免重写他人依赖的历史只想把主线的 bugfix 带回自己的长期分支merge保留真实合并关系后续 rebase 更省心开 PR 前想整理提交信息交互式 rebasegit rebase -i可以合并、拆分、修改提交顺序和消息6.3 交互式 rebase整理提交的利器很多团队要求提交历史有清晰的结构不喜欢“fix typo”“add something”“oops”这类碎提交。交互式 rebase 就能派上用场。git rebase -i HEAD~3这会打开一个编辑界面展示最近 3 个提交的列表。你可以把pick改成squash把某个提交合并到前一个里也可以修改提交顺序甚至edit某个提交并重新改动。这里我要强调一件事交互式 rebase 不是让你硬造一个“从不犯错”的假历史而是让那条历史链中的每一次提交都有一个完整、可读的语义单元。对后来的维护者来说一条干净的历史比 20 个“wip”提交要有价值得多。7. 实操中的常见混战与排查心得理解再多的概念最终还是要落到每天面对的终端和代码里。这一节整理几个我实际工作中频繁遇到、也是新手最容易慌的场景。7.1 文件冲突不一定是你改错了第一次遇到合并冲突很多人会本能地觉得“是不是我把别人的代码弄坏了、要不要重新 clone”。其实冲突只是一个正常的“需要你决策”的信号。解决冲突的推荐顺序是确认当前在哪个分支、要合并哪个分支。git status会列出冲突文件逐个打开冲突文件搜索、、标记决定保留哪边、删除哪边还是做手动融合确认结果后git add file所有文件都解决后执行git merge --continue/git rebase --continue/ 直接git commit看处于哪种操作中最后在本地跑一次构建和测试确保解决冲突的过程没有引入新问题。我个人有个习惯冲突内容较多时不直接在编辑器的“采用当前/采用对方”按钮里快速选边。先用git diff把双方改动完整看一遍再打开一次全貌因为两个分支可能只是“各自改了同一个函数”但上下文已经完全不同只按按钮很可能丢掉语义。注意能自动合并的情况里也有隐患。比如一个分支改了某个函数实现另一个分支改了调用处注释Git 能合并但结果未必符合预期。合并不报错不代表逻辑正确合并完要多跑测试。7.2 误删、误提交、误 reset 的挽回现场先讲最“急救”的工具reflog。它是 Git 的本地日志记录了你每一次操作引起的 HEAD 变化。git reflog输出里会列出你最近做过的 reset、commit、checkout、merge 等操作以及操作前后的提交哈希。假设你误执行了git reset --hard HEAD~3发现刚才的三次提交不见了。打开 reflog找到 reset 之前 HEAD 指向的哈希然后执行git reset --hard 那个哈希就可以把分支指针拉回来工作区也会恢复到当时的状态。这是我自己恢复过不止一次“看起来丢了”的提交。另外如果你只是漏了某个文件没有提交但已经 commit别急着 reset。可以先git add 漏掉的文件 git commit --amend它会把你漏掉的文件补到上一个提交里生成一个新的提交替掉旧的。注意如果这个提交已经 push 到了远端--amend也会产生重写历史的效果需要谨慎一般只用于本地提交。还有个常见误场景想丢弃工作区某个文件的改动恢复成 HEAD 版本git restore file比git checkout -- file更贴近直觉老命令你偶尔也能在文档里看到但新项目用restore就好。反过来如果发现改错了想回到暂存区里的某个版本可以用git restore --staged file把文件从暂存区撤回工作区。7.3 日常协作里最值得养成的几个习惯代码写多了之后你会发现“理解 Git”不等于“把每个命令都记住”而是在团队合作里养成几个不会让彼此难受的习惯。第一提交之前先用git status和git diff自查一遍。我经常看到新人一股脑git add .把密码、构建产物、不该提交的临时文件全部塞进去了。git status能让你看见工作区里所有“未跟踪文件”特别是那些不认识的.log、.env文件。配合.gitignore可以把常见产物都提前挡在外面。第二提交信息要有语义。不是一个笼统的“update”而是简单描述“这段改动做了什么、为什么”。这样日后看git log或做代码评审时不需要一句句猜代码。第三遇到搞不定的仓库状态先别急着删目录。几乎所有的 90% 的 Git 问题都有一句通用的保命咒语git status和git reflog。它们会告诉你当前在哪、以及之前经过了哪里。删目录重来虽然最快但会让你错过学习和理解仓库结构的机会下次还是会在同一个坑里栽倒。第四推送前多确认一次。git push本身不可怕可怕的是加上了--force或--force-with-lease。我在本地演示分支上用强制推送已经习以为常但在共享分支上除非你有明确的团队纪律否则尽量避免。如果真的需要重写远端历史先和所有涉及到的同事同步选一个大家都不在拉取的窗口再操作。最后分享一个我自己的体会学 Git 不是背指令而是学“模型”。第一次看到别人用一条我没见过的命令时我不会急着抄而是先想想这条命令操作的是哪棵树移动的是哪个指针会影响谁一旦这样思考绝大部分命令都很容易归类。后面你遇到任何 Git 报错第一反应也不会是复制粘贴网上脚本而是先看git status再看报错提示里提到的具体文件和引用这一步做多了你会比用了一两年 GUI 工具的同事更稳。