Git

也常被叫作：版本控制版本管理代码仓库

版本与协作通常止于「运行时」约 1 分钟读完

你可能会这么说

「让 AI 每次改动都留下一个「存档点」，改坏了能退回上一个存档。」

Git Git

一套记录文件每次改动、并能在任何时候退回任意历史版本的工具。

Git 的核心不是「备份」，是记录每一次改动。备份是覆盖式的——存的是最新那份；Git 存的是一串连续的历史：谁、在什么时候、改了哪几个文件、为什么改。有了这条时间线，你就不只回得到昨天，而是回得到任意一个你想回去的那一天。

对你来说最有用的三个画面是：改坏了能退回去、同时改两件事不会互相踩、AI 干的活出了问题你知道是哪一版出的。前两个是日常，第三个是追责和定位的关键——当线上出问题，你能从提交记录里立刻看出「这个 bug 是哪次改动带进来的」。

多数人用 Git 就够用三件事：commit（存一个档）、branch（开一条独立的线）、merge（把两条线合起来）。命令背不全没关系，但要理解「存档点越多，越容易退回」。最怕的不是不会用命令，是改了半天一个档都不存，最后想退都没得退。

长什么样真实可交互，不是截图

提交 1：加登录页→提交 2：修按钮样式→提交 3：改坏了？退回提交 1

当前：提交 1提交 3 被丢弃

历史不是盖新的盖旧的，是一条可以来回跳的线。提交 3 做坏了，你跳回提交 1，前面几版都还在记录里。

拆开看，里面有这几块

1
提交 Commit
一个存档点，记录「这一版改了哪些文件、为什么改」。改得小一点、勤一点，退回时粒度才细。
2
分支 Branch
一条独立的改动线。主线（通常叫 main）保持稳定，新活开分支做，做完再合回来。
3
工作区 Working tree
你磁盘上正在改的文件。改完了不存档，退出时就丢了。
4
暂存区 Staging area
提交前的「待办筐」：把要存进下一个档的文件先放进来。可以只放一部分，不强制一次存所有。
5
远程仓库 Remote
存在别人服务器上的那份副本，用来多人协作和备份。本地机器烧了它还在。

常见的有哪几种

本地使用Local only

只在你自己电脑上记录历史，不推到任何服务器。

用在：单人小项目、刚开始练手

远程协作With remote

推到 GitHub / GitLab 等，多人共享同一份历史。

用在：多人一起写、需要异地备份

容易搞混？这样区分

Git ≠ 备份 / 网盘同步 Backup / Cloud sync

备份存的是「最新的那份」，覆盖式，没有历史；Git 存的是「每一次改动」，能回到任意版本。区别就是：备份回答「现在是什么」，Git 回答「以前是什么、哪一版开始坏」。

看备份 / 网盘同步

Git ≠ 部署 Deploy

Git 是记录和管理代码版本，部署是把某个版本放到线上跑起来。很多人把「推到 Git 仓库」当成了「上线」——推上去只是记录，线上没变。

看部署

什么时候用得上

改坏了要退回

每次改动前先存一个档，改坏了就退回，而不是靠记忆手动重做。

并行改两件事

修 bug 开一个分支、加功能开另一个分支，互不干扰，做完各自合回来。

定位线上 bug

线上出问题，看哪次提交带进来的，直接退回或针对那次提交改。

你可以这样跟 AI 说

直接复制下面这段，把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了：改哪里、不许动啥、做完交什么。

【任务】用 Git 管理 [项目目录]，每次改动前先告诉我你的计划
【范围】只初始化仓库和做日常提交，不改动任何业务代码
【边界】
  - 不要提交包含密钥、密码、账号、.env 这类敏感文件
  - 不要让 AI 在没经过我确认时直接覆盖或回退我已有版本
  - 每次提交用一句话说明「这次改了什么、为什么」，不写「update」这种空话
【交付】
  1. 初始化后把远程仓库地址给我
  2. 每次你改完一段代码就自动提交一次，并把提交编号和说明列出来
  3. 我需要退回时，告诉我应该执行哪一条命令，而不是直接替我做

这段需求的关键是「把边界说死」：不让提交敏感文件、不擅自回退、提交信息说清楚原因。AI 默认会图省事，把「存一版」当成「存了再说」，这三条边界挡住了最常见的坑。

它说「做好了」，你怎么自己验

这是本站的重头戏。AI 最会的不是写代码，是说「已完成」。这一条，它通常最多做到「运行时」这层：真的跑起来了，能在本机看到结果。

要亲眼看到这些，才算数

在你的项目目录跑一条查看提交历史的命令，能看到不止一个有意义的提交，提交说明不是「update」「done」这种空话。
手动改一个文件然后提交，提交后立刻改动它，再用「查看某个历史版本」的命令，确认能回到你改动之前的那个版本——历史真的可回退，不是只存了个日志。
检查敏感文件：让 AI 列出提交历史里出现过哪些文件，确认里面没有 .env、密钥、密码这类文件。
让 AI 把远程仓库地址贴出来，并确认本地和远程是同一个仓库（推送时地址能对上）。

它常这么糊弄你

「Git 已经配好了」——但项目目录里其实没有提交记录，只是装了个 Git 而已。
「我提交过了」——提交说明全是「update」「wip」「fix」。说明你没让 AI 交代清楚，退回时你根本分不清哪个是哪个。
「历史很完整」——但你让他列出历史文件时，发现 .env 这种敏感文件也在里面。这是事故，不是完成。
「已经推送到远程了」——但远程地址根本不存在，或者推的是另一个目录。让他贴出地址你再核对。

Git 自己就能验到「运行时」层：命令是真的跑起来、历史真的可回退，你在本地就能亲手验证。要提到「生产」层，还需要多人协作规范、分支保护和权限这些管理层面，那已经不是单人本地能验的范围。

考考你选一个你觉得对的

AI 说「我已经用 Git 管理这个项目了」。你想最快确认他真的做到了，哪一步最有用？

想再深挖一点靠谱出处

Git 官方网站Git 官方 ↗Git 官方文档（docs）Git 官方 ↗Pro Git 中文版Git 官方 ↗

# Git (Git)

> 一套记录文件每次改动、并能在任何时候退回任意历史版本的工具。

**你可能会这么说**：让 AI 每次改动都留下一个「存档点」，改坏了能退回上一个存档。

Git 的核心不是「备份」，是记录每一次改动。备份是覆盖式的——存的是最新那份；Git 存的是一串连续的历史：谁、在什么时候、改了哪几个文件、为什么改。有了这条时间线，你就不只回得到昨天，而是回得到任意一个你想回去的那一天。 对你来说最有用的三个画面是：改坏了能退回去、同时改两件事不会互相踩、AI 干的活出了问题你知道是哪一版出的。前两个是日常，第三个是追责和定位的关键——当线上出问题，你能从提交记录里立刻看出「这个 bug 是哪次改动带进来的」。 多数人用 Git 就够用三件事：commit（存一个档）、branch（开一条独立的线）、merge（把两条线合起来）。命令背不全没关系，但要理解「存档点越多，越容易退回」。最怕的不是不会用命令，是改了半天一个档都不存，最后想退都没得退。

**也叫**：版本控制、版本管理、代码仓库

## 你可以这样告诉 AI

```text
【任务】用 Git 管理 [项目目录]，每次改动前先告诉我你的计划
【范围】只初始化仓库和做日常提交，不改动任何业务代码
【边界】
  - 不要提交包含密钥、密码、账号、.env 这类敏感文件
  - 不要让 AI 在没经过我确认时直接覆盖或回退我已有版本
  - 每次提交用一句话说明「这次改了什么、为什么」，不写「update」这种空话
【交付】
  1. 初始化后把远程仓库地址给我
  2. 每次你改完一段代码就自动提交一次，并把提交编号和说明列出来
  3. 我需要退回时，告诉我应该执行哪一条命令，而不是直接替我做
```

## 怎么验证他真的做到了

通常止于层级：**运行时** — 真的跑起来了，能在本机看到结果

- [ ] 在你的项目目录跑一条查看提交历史的命令，能看到不止一个有意义的提交，提交说明不是「update」「done」这种空话。
- [ ] 手动改一个文件然后提交，提交后立刻改动它，再用「查看某个历史版本」的命令，确认能回到你改动之前的那个版本——历史真的可回退，不是只存了个日志。
- [ ] 检查敏感文件：让 AI 列出提交历史里出现过哪些文件，确认里面没有 .env、密钥、密码这类文件。
- [ ] 让 AI 把远程仓库地址贴出来，并确认本地和远程是同一个仓库（推送时地址能对上）。

常见糊弄：
- 「Git 已经配好了」——但项目目录里其实没有提交记录，只是装了个 Git 而已。
- 「我提交过了」——提交说明全是「update」「wip」「fix」。说明你没让 AI 交代清楚，退回时你根本分不清哪个是哪个。
- 「历史很完整」——但你让他列出历史文件时，发现 .env 这种敏感文件也在里面。这是事故，不是完成。
- 「已经推送到远程了」——但远程地址根本不存在，或者推的是另一个目录。让他贴出地址你再核对。

来源：https://mickerbook.com/reference/t/git/