来源：https://github.com/datawhalechina/vibe-vibe

本节目标：理解 Git 的核心价值——它解决了什么问题，以及你可能已经在用它了。

你可能已经在用 Git 了

这里有个有趣的事实：如果你一直跟着本书用 Claude Code 开发项目，你的项目目录里很可能已经有一个 .git 文件夹了。

Claude Code 在创建新项目时，通常会自动执行 git init 初始化仓库，并在开发过程中帮你提交代码。换句话说，你一直在用 Git，只是没意识到。

打开终端，进入你的项目目录，运行 git log --oneline -5。如果看到一串提交记录，那就对了——Claude Code 一直在帮你"存档"。这个发现本身就是一个觉醒时刻：你一直在用的工具，现在该理解它了。

这就像你一直在用手机的自动备份功能，照片默认同步到了云端，但你从来没打开过云相册看一眼。某天手机摔坏了，你才发现——原来照片都在云端，一张没丢。Git 对你的代码做的就是类似的事，只不过它记录的不只是"最新版本"，而是每一次修改的完整历史。

如果你的项目还没有 Git 仓库也没关系，告诉 Claude Code 帮你初始化一个就行。Windows 用户注意：.git 是隐藏文件夹，如果在文件管理器里看不到，直接运行 git status，有输出就说明仓库存在。

三区模型：你的修改在哪里

Git 管理代码有三个区域，理解它们能帮你回答一个关键问题："我的修改现在在哪里？"

┌─────────────┐    git add    ┌─────────────┐   git commit   ┌─────────────┐
│   工作区     │ ──────────→  │   暂存区     │ ──────────→   │  本地仓库    │
│ Working Dir  │              │ Staging Area │               │  Local Repo  │
└─────────────┘              └─────────────┘               └─────────────┘
  你正在编辑的文件              准备提交的修改                  已保存的版本历史

打个比方：工作区是你的书桌——文件摊开在上面，你正在改。暂存区是你整理好的一摞纸——"这些是我要交的"。本地仓库是档案柜——交上去的东西永久保存。你在书桌上涂涂改改（工作区），觉得满意了就把改好的纸整理成一摞放到旁边（暂存区），最后把这摞纸归档到柜子里（本地仓库）。这三步对应的就是"编辑文件 → git add → git commit"。

日常开发中，Claude Code 会帮你处理这些步骤，你不需要手动执行 git add 和 git commit。但当你遇到"我刚才的修改去哪了"或"为什么提交里没有这个文件"的困惑时，三区模型能帮你定位问题。

文件改了但 git status 显示"未暂存"，说明修改还在工作区，没有 add。add 了但没 commit，说明修改在暂存区，还没存档。commit 了但没 push，说明存档在本地，还没同步到云端——这个下一节会讲。

你不需要死记这些命令。重要的是建立一个心智模型：修改从工作区出发，经过暂存区，最终进入本地仓库。每一步都是可控的，你随时可以问 Claude Code "我的修改现在在哪个阶段"。

就像你出门前下意识看一眼手机电量——不是每次都需要充电，但看一眼心里有底。git status 就是这一眼：它告诉你哪些文件被修改了但还没暂存，哪些已暂存但还没提交，当前在哪个分支上。Claude Code 在执行 Git 操作前通常会自动检查状态，但当你感到困惑时，知道有这个工具能帮你定位问题。

查看历史：AI 到底改了什么

用 Claude Code 开发时，AI 会频繁修改文件。有时候你想知道"它刚才到底改了什么"或者"昨天的代码长什么样"。Git 的提交历史就是你的答案。每条提交记录包含谁在什么时候做了修改、修改了哪些文件、每个文件具体改了哪几行。

你不需要记住 git log、git diff、git show 这些命令的区别。告诉 Claude Code 你想看什么——"最近改了什么""上次提交的内容""这个文件的修改历史"——它会选择合适的命令并把结果解释给你。

这在 AI 编程中尤其有用。有时候 Claude Code 一次性改了好几个文件，你想确认它改的对不对，看一眼 diff 比重新读整个文件快得多。Word 里的"修订模式"你大概用过——删掉的字划红线，新加的字标蓝色。diff 就是代码世界的修订模式，用绿色标出新增的行、红色标出删除的行，一目了然。养成"改完看 diff"的习惯，能帮你更好地理解 AI 做了什么，也能及时发现不符合预期的修改。

查看历史还有一个不那么明显但很重要的用途：理解代码的演变过程。当你看到一段代码不理解它为什么要这么写时，查看这个文件的提交历史，往往能找到答案。也许三次提交之前这段代码更简单，后来因为修了一个 bug 才变成现在这样。提交信息里可能写着"fix: 处理用户未登录时的空指针异常"——你立刻就明白了这段看起来多余的判断是在防什么。代码本身只告诉你"是什么"，提交历史告诉你"为什么"。

下一节：代码只在你的电脑上，朋友拿不到，硬盘坏了就全没了。11.2 推上云端，开始协作 解决这个问题。