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 里的“保存”覆盖旧版本，Ctrl+Z 可能撤销连续几步，但 Git 完全不同：Git 的每一次提交不是“覆盖”，而是“新增一个永久对象”，并且这个对象会记录它的父提交是谁。打个比方，普通的保存像拍一张拍立得，贴到相册里，相册满了就把旧照片丢进垃圾桶；Git 的提交像在一条时间线上加一个“密封舱”，每个舱都标着“我在哪个时间点进来，我继承自哪个舱”。旧舱不会因为你加了新舱而消失，你随时可以回到任意一个舱内部。这个区别是所有后续理解的地基：Git 是一个不可变的、带时间线的、有向无环图（DAG）。你可能听到过 DAG 这个词，没关系，后面我会用更具体的方式拆开它。2. Git 的对象模型：一切的底层要理解 Git，绕不开四个内部对象：blob、tree、commit、tag。它们不常被初学者注意到，但理解了它们，你对“分支”“合并”“重置”的很多困惑会自动解开。2.1 blob、tree、commit：Git 把“版本”拆成了什么直接看一个例子。你在项目里有一个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之后又改了文件，如果不重新add，commit 里包含的是旧版本，不是最新版本。这是新手最容易犯的“漏提交”问题。4. 分支与 HEAD：Git 的“指针”世界观4.1 分支是指针，不是文件夹很多用过 SVN 的人第一次看到 Git 分支，会下意识认为分支是“代码的另一个副本文件夹”。这是对 Git 最大的误解之一。在 Git 里，分支只是一个“可移动的指针”——指向某个 commit 对象。假设当前分支叫main，它指向 commita1b2c3。当你在这个分支上提交了新的 commitd4e5f6，main指针就会自动向前移动，指向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 游离 HEAD（detached 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，你写了若干改动，部分已add：git 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 前想整理提交信息交互式 rebase（git 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 工具的同事更稳。
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 里的“保存”覆盖旧版本，Ctrl+Z 可能撤销连续几步，但 Git 完全不同：Git 的每一次提交不是“覆盖”，而是“新增一个永久对象”，并且这个对象会记录它的父提交是谁。打个比方，普通的保存像拍一张拍立得，贴到相册里，相册满了就把旧照片丢进垃圾桶；Git 的提交像在一条时间线上加一个“密封舱”，每个舱都标着“我在哪个时间点进来，我继承自哪个舱”。旧舱不会因为你加了新舱而消失，你随时可以回到任意一个舱内部。这个区别是所有后续理解的地基：Git 是一个不可变的、带时间线的、有向无环图（DAG）。你可能听到过 DAG 这个词，没关系，后面我会用更具体的方式拆开它。2. Git 的对象模型：一切的底层要理解 Git，绕不开四个内部对象：blob、tree、commit、tag。它们不常被初学者注意到，但理解了它们，你对“分支”“合并”“重置”的很多困惑会自动解开。2.1 blob、tree、commit：Git 把“版本”拆成了什么直接看一个例子。你在项目里有一个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之后又改了文件，如果不重新add，commit 里包含的是旧版本，不是最新版本。这是新手最容易犯的“漏提交”问题。4. 分支与 HEAD：Git 的“指针”世界观4.1 分支是指针，不是文件夹很多用过 SVN 的人第一次看到 Git 分支，会下意识认为分支是“代码的另一个副本文件夹”。这是对 Git 最大的误解之一。在 Git 里，分支只是一个“可移动的指针”——指向某个 commit 对象。假设当前分支叫main，它指向 commita1b2c3。当你在这个分支上提交了新的 commitd4e5f6，main指针就会自动向前移动，指向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 游离 HEAD（detached 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，你写了若干改动，部分已add：git 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 前想整理提交信息交互式 rebase（git 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 工具的同事更稳。