A

你的 AI 刚改了 30 个文件，你敢点「接受」吗？

#技术#学习#AI 素养#工作流#智能体

内容概要

git 不再只是程序员的工具。智能体一次改几十个文件、多个任务并行跑、连你的知识库都在被它改写——这三件事都需要一个能追溯、能回退的底座。你不用背命令：搞懂工作区、暂存区、本地仓库、远程仓库这四个区域，剩下的交给智能体，你负责审查。下面的交互手册可以点着玩：四区模拟器、分支沙盒、25 条指令的原理与影响，以及现成的提示词。

先看三个场景。

场景一：vibe coding。 现在没有编程经验的人，也可以让智能体帮忙写网页、做小工具。但智能体一次动辄修改几十个文件，如果做到一半发现方向不对，你需要有办法回到它动手之前的样子，这颗后悔药靠的就是 git。

场景二：智能体自己的工作方式。 主流的编程智能体也在借用 git 的机制，比如 Claude Code 通过 git worktree 让多个任务同时进行、互不覆盖，改了什么、什么时候改的，也能从提交记录里追溯。

场景三：个人知识库。 Karpathy 分享过一种 LLM Wiki 的做法，让智能体持续整理和维护一批互相链接的 Markdown 笔记，他在说明里提到，这个 wiki 本质上就是一个 git 仓库，版本历史和分支都是现成的。智能体每天替你改笔记，你总得知道它改了什么，改错了能不能恢复。

所以问题不是要不要学 git，而是怎么学得轻松一点。

这份手册是写给谁的

我做了一份交互式的 Git 机制手册，面向没有编程背景的人。它先用四个区域讲清运作原理：工作区是你正在编辑的文件，暂存区是挑出「这次要存档」的改动，本地仓库是永久保存的历史，远程仓库是云端的共享备份。所有指令，本质上都是在这四个地方之间搬运内容。

你不用硬背命令，在模拟器里点一点就能看懂。开分支、并行任务、审查成果、合并、撤销、收工推送这些主要场景，手册都备好了现成的提示词，复制给智能体，命令由它来敲。

怎么用

建议先看「全景」认识四个区域，再去「模拟」和「分支」里亲手操作几遍。平时遇到具体场景，就到「指令库」和「对话」里复制提示词；万一出了岔子，直接翻到「救援」。

手册就在下面，可以直接点。

Nexus · 交互手册

Git 机制手册

Snapshots, pointers, and a safe way to let agents work in parallel.

你不需要背命令，但需要看得懂智能体在你的仓库里做了什么。这份手册把 git 拆成四个区域、四个概念，每条指令都讲清楚：原理、什么时候用、会改变什么，以及怎么对智能体说。

点箭头看指令在模拟器里亲手操作提示词一键复制

01 · 全景

四个区域，一条流水线

所有 git 指令，本质上都是在这四个地方之间搬运内容。先记住这张图，后面每条指令都能对号入座。

工作区

Working Directory

你能看到、能编辑的文件

暂存区

Staging Area

下一次提交的「草稿」

本地仓库

Local Repository

你机器上的完整历史（.git）

远程仓库

Remote Repository

GitHub 上的那一份

类比：网购下单工作区是货架前你随手翻的商品；暂存区是购物车，你挑出这一单要结算的东西；本地仓库是已经开出的小票，一旦开出就不能涂改；远程仓库是把小票同步到公司云端，别人才看得到。add 是放进购物车，commit 是结账开票，push 是上传小票。
注意：仓库放哪里git 仓库建议只放在本地的代码目录里。把带 .git 的文件夹放进 iCloud 这类同步目录，同步冲突可能损坏仓库内部文件，这是常见的坑。

02 · 底层

只需理解四件事

理解这四件事，你就明白为什么分支很便宜、为什么「改写历史」其实是造了新提交。

git 存的不是「每次改了哪几行」，而是每次提交时整个项目的快照。没变的文件不会重复存，只是引用旧的那份，所以并不浪费空间。

你看到的 diff，是拿两个快照现场算出来的差异，并不是存下来的。

快照 A快照 B快照 C
git cat-file -p HEAD         # 看最近一次提交的内容
git cat-file -p HEAD^{tree}  # 看那次提交对应的目录

每个提交有一个像 5d6a2d 这样的指纹，由内容、父提交、作者、时间、信息一起算出来。

只要有一点不同，哈希就全变。所以 rebase、amend 这类「改历史」，其实是造了一批新提交，旧的还在，只是没人指着它们。

93d4265d6a2d3ja3ro

每个提交都记着父提交的哈希，串成一条链。改动中间任何一个，后面所有的哈希都会变。这也是 git 能发现文件被悄悄篡改的原因。

分支只是一个小文件，里面写着某个提交的哈希。新建分支几乎零成本：只是多贴一个标签。

你提交时，当前分支的标签会自动前移到新提交。这就是「分支」的全部秘密。

…5d6a2d3ja3ro
main → 3ja3rofeature → 5d6a2d
cat .git/refs/heads/main    # 一行哈希

HEAD 是「你现在站在哪儿」的指针，通常指向当前分支。git switch 的本质，就是移动 HEAD，并把工作区换成那个位置的快照。

如果 HEAD 直接指向某个提交而不是分支，就叫 detached HEAD（游离状态）。在这里做的提交，没有分支保护，切走后容易丢失。想保留就 git switch -c 新分支名。

HEADmain3ja3ro
cat .git/HEAD
# ref: refs/heads/main

03 · 模拟

四区模拟器：亲手推一遍

按顺序点：编辑文件、add、commit、push。然后试试「同事推了新提交」，再 push 看看会发生什么。

04 · 分支

分支沙盒：分叉与合并

圆点是提交，标签是分支指针，橙色高亮的是 HEAD 所在的分支。先在 main 上提交几次，再新建分支各自提交，最后合并。

05 · 并行

为什么智能体时代必须懂 worktree

多个智能体同时在一个文件夹里改代码，会互相踩脚。worktree 让同一个仓库同时展开成多个目录，每个目录站在不同的分支上。

.git 数据库（只有一份）所有提交、分支、历史共享

~/Code/app

main

你自己的主目录。始终保持干净，作为参照和最终合并点。

~/Code/wt-auth

agent/auth

智能体 A 的工作间。只改登录相关，不会影响主目录。

~/Code/wt-docs

agent/docs

智能体 B 的工作间。只改文档，进度互不打扰。

git worktree add ../wt-auth -b agent/auth   # 新目录 + 新分支
git worktree list                           # 看有哪些工作间
git worktree remove ../wt-auth              # 用完清理

和你用的工具怎么对应

Claude Code：本地用 worktree 或 agent 视图，每个后台会话拥有自己的工作间，互不覆盖。

云端会话：每个线程是一条独立会话，跑在自己的分支上，冲突按普通合并冲突处理。一个任务一个线程一条分支。

子智能体委派：把子任务放进各自的 worktree 隔离，每个子智能体一条分支，汇总时再合并。

六条并行规矩

  1. 分支按任务命名，如 agent/auth，不要叫 session-2。
  2. 同一分支不能同时在两个工作间里检出。
  3. 每个工作间要各自安装依赖。
  4. 派活前写清范围，越界的改动最难审。
  5. 合并前看 diff，一次只合一条。
  6. 起步 2 到 3 个并行，先别贪多。

06 · 指令库

每条指令：原理、场景、影响、提示词

「影响」里的四个小标签，对应第一张图的四个区域，亮起的就是这条指令会改变的地方。

工作区暂存区本地仓库远程仓库

  • git init在当前目录创建隐藏的 .git 文件夹
  • git init -b main同时指定默认分支名
原理

创建 .git 目录，里面就是整个仓库数据库：对象库、分支指针、配置。你的文件本身一个字节都不会动。

使用场景

新项目第一次想被版本管理的时候。

影响

只新增 .git。删掉 .git 就等于删掉全部历史，文件本身保留。

给智能体的提示词
在当前目录初始化 git 仓库，默认分支叫 main。添加一个适合本项目语言的 .gitignore，先告诉我会把哪些文件纳入版本管理，等我确认后再做首次提交，提交信息写 init。

工作区暂存区本地仓库远程仓库

  • git clone <URL>完整历史，自动把远程命名为 origin
  • git clone --depth 1 <URL>只取最新快照，快，但没有完整历史
原理

先下载远程仓库的全部对象，再检出默认分支到工作区，并把远程记为 origin。你得到的是一个完整独立的副本，不是「快捷方式」。

使用场景

第一次拿到别人的项目，比如 GitHub 上的开源项目。

影响

新建一个目录，对远程没有任何影响。

给智能体的提示词
把 <仓库 URL> 克隆到本地的代码目录下。克隆完成后告诉我：默认分支是什么、最近 5 条提交、README 里的启动步骤。不要运行任何安装或启动命令。

工作区暂存区本地仓库远程仓库

  • git status完整版
  • git status -sb精简版，一行一个文件
原理

比较三处：工作区、暂存区、最近一次提交，并列出它们之间的差异，同时告诉你所在分支以及与远程的领先或落后。

使用场景

任何操作之前和之后。它是 git 里最该养成习惯的一条。

影响

只读，不改变任何东西。

给智能体的提示词
运行 git status，然后用中文告诉我：我在哪个分支；哪些改动还没暂存，哪些已暂存；有没有未跟踪的新文件；本地比 origin 领先或落后几个提交。

工作区暂存区本地仓库远程仓库

  • git diff工作区 对比 暂存区（还没 add 的改动）
  • git diff --staged暂存区 对比 最近提交（即将提交的内容）
  • git diff main...agent/xagent/x 分支自分叉以来新增的改动
原理

diff 不是存下来的，而是拿两个快照现场算出来的差异。加不同参数，就是选择拿哪两个快照对比。

使用场景

提交前自查，合并前审查智能体的产出。审查是你在并行时代最重要的工作。

影响

只读。

给智能体的提示词
用 git diff main...agent/<分支名> 看这条分支相对 main 改了什么。按文件汇总，用中文说明每个文件改了什么、为什么可能这么改。特别标出：超出任务范围的改动、删除的文件、配置或依赖的变化。

工作区暂存区本地仓库远程仓库

  • git log --oneline --graph --all一屏看清所有分支的形状
  • git log -p <文件>某个文件的历史改动
  • git show <提交>某一次提交的详情
原理

每个提交记着自己的父提交，log 就是顺着这条「父子链」往回走。

使用场景

想知道某个改动是谁、什么时候、为什么做的。

影响

只读。

给智能体的提示词
运行 git log --oneline --graph --all -20，用中文帮我概括：现在有哪些分支、它们各自领先 main 几个提交、最近一次合并发生在什么时候。

工作区暂存区本地仓库远程仓库

  • git add <文件>暂存指定文件
  • git add -p逐块挑选要暂存的改动
  • git add -A全部暂存（小心带上不该提交的文件）
原理

把文件此刻的内容拍一张快照，写进暂存区。之后你再改这个文件，暂存区里的仍是拍照时的版本，新的改动要重新 add。

使用场景

你想精确控制「这次提交包含什么」时。比如同时改了三处，但想分成两次提交。

影响

只改变暂存区，不动文件，也不产生历史。

给智能体的提示词
只暂存与「<任务描述>」相关的文件，然后运行 git status 给我看清单。不要使用 git add -A，不要暂存 .env、密钥、日志或大文件；如果发现这类文件，先停下来告诉我。

工作区暂存区本地仓库远程仓库

  • git commit -m "信息"用一句话说明
  • git commit --amend修改最近一次提交（仅限还没 push 的）
原理

把暂存区的快照，连同作者、时间、信息、父提交的指向，打包成一个不可变的提交对象；当前分支指针前移到它。

使用场景

一个逻辑完整的小步骤完成时。经验是：一个提交只做一件事。

影响

本地历史新增一条。push 之前只有你自己看得到，随时可以调整。

给智能体的提示词
把已暂存的改动提交。提交信息用祈使句，说明「为什么这么改」，不只是「改了什么」。提交前先跑一遍测试，测试不过就不要提交，告诉我失败原因。

工作区暂存区本地仓库远程仓库

  • .gitignore每行一条规则，例如 node_modules/、.env、*.log
  • git rm --cached <文件>已经被跟踪的文件，要先从索引中移除
原理

一个普通文本文件，git 在 status 和 add 时按它过滤。注意：只对「还没被跟踪」的文件生效。

使用场景

依赖目录、构建产物、密钥文件、系统临时文件。

影响

不改历史。已经提交过的敏感文件，加规则也不会从历史里消失。

给智能体的提示词
检查项目根目录有没有 .gitignore。按本项目使用的语言和工具补全，务必包含 .env、密钥文件、依赖目录、构建产物、系统临时文件。检查是否已有这类文件被跟踪，有的话告诉我，不要自行删除。

工作区暂存区本地仓库远程仓库

  • git fetch更新所有 origin/* 引用
  • git fetch --prune顺便清掉远程已删除分支的本地引用
原理

把远程的新提交下载到本地，记在 origin/main 这类「远程跟踪分支」上。你自己的分支和工作区一根毛都不动。

使用场景

想先看看别人改了什么，再决定怎么合并。比 pull 更稳。

影响

只更新远程跟踪引用，安全。

给智能体的提示词
先运行 git fetch，然后告诉我：本地 main 和 origin/main 有没有分叉；远程新增了哪些提交，谁提交的，改了哪些文件。先不要合并，等我确认。

工作区暂存区本地仓库远程仓库

  • git pullfetch + merge
  • git pull --rebasefetch + rebase
  • git pull --ff-only只允许快进，否则报错，最安全
原理

先 fetch，再把远程分支并入当前分支。如果你本地有没推送的提交，就会产生一个合并提交或触发冲突。

使用场景

确定要立刻同步最新代码时。

影响

会改变工作区文件，可能产生合并提交或冲突。

给智能体的提示词
同步远程最新代码，使用 git pull --ff-only。如果不能快进，说明本地和远程已经分叉，请不要自动合并，先告诉我双方各有哪些提交。

工作区暂存区本地仓库远程仓库

  • git push -u origin <分支>首次推送并建立跟踪关系
  • git push之后直接推
  • git push --force-with-lease比 --force 安全的强推，仍属高危
原理

把远程没有的提交上传，并把远程分支指针前移。如果远程有你没有的提交，git 会拒绝，这是在保护别人的工作。

使用场景

一个阶段完成、想备份或让别人看到的时候。

影响

影响所有协作者。强推会覆盖远程历史，别人的提交可能消失。

给智能体的提示词
把当前分支推送到 origin。推送前确认当前分支不是 main；不允许使用任何 force 参数。如果被拒绝，把原因用中文告诉我，先不要尝试绕过。

工作区暂存区本地仓库远程仓库

  • git remote -v看远程地址
  • git remote add origin <URL>添加一个远程
原理

origin 只是一个名字，指向一个 URL。你可以给同一个仓库配多个远程，比如 origin 和 upstream。

使用场景

新建本地仓库后想关联 GitHub；fork 开源项目后想跟上游同步。

影响

只改配置。

给智能体的提示词
运行 git remote -v，告诉我当前仓库关联了哪些远程、地址分别是什么，以及当前分支跟踪的是哪个远程分支。

工作区暂存区本地仓库远程仓库

  • git branch列出本地分支
  • git branch <名>在当前提交上新建，不切换
  • git branch -d <名>删除已合并的分支
原理

分支本质上是一个写着某个提交哈希的小文件。新建分支就是多贴一个标签，几乎零成本；你提交时，当前分支的标签自动前移。

使用场景

开始任何新任务前。习惯是：一个任务一条分支。

影响

只新增或删除指针，不动任何提交内容。

给智能体的提示词
从最新的 main 新建分支 agent/<任务名>，并切换过去。之后所有改动都只在这条分支上做，不要动 main。

工作区暂存区本地仓库远程仓库

  • git switch <分支>切到已有分支
  • git switch -c <新分支>新建并切换
  • git checkout <分支>老写法，功能重叠且容易混淆
原理

把 HEAD 指向另一条分支，并把工作区和暂存区换成那条分支最新提交的快照。git checkout 是老命令，一个命令干了太多事，2.23 版起被拆成 switch（切分支）和 restore（恢复文件）。

使用场景

在不同任务之间来回。

影响

工作区文件会变。如果有未提交改动会冲突，git 会拒绝并提示。

给智能体的提示词
切换到分支 <分支名> 之前，先运行 git status。如果有未提交的改动，先告诉我，问我是提交、stash 还是放弃，不要自行处理。

工作区暂存区本地仓库远程仓库

  • git merge <分支>并入当前分支
  • git merge --no-ff <分支>即使能快进也留一个合并提交
  • git merge --abort冲突时放弃合并
原理

找到两个分支的共同祖先，做三方比较。如果当前分支没有新提交，就直接「快进」移动指针；否则生成一个有两个父提交的合并提交；同一处被两边修改，就停下来等你解决冲突。

使用场景

某个任务分支完成、审查通过后，并回 main。一次只并一条。

影响

改变当前分支的历史；冲突时会在文件里留下标记。

给智能体的提示词
我在 main 上。先运行 git diff main...agent/<分支名> 给我一份中文摘要，等我确认后再合并。合并后跑测试。有冲突时先列出冲突文件，并解释两边各自的意图，不要自己选一边。

工作区暂存区本地仓库远程仓库

  • git rebase main把当前分支的提交在 main 最新位置重放
  • git rebase --abort放弃
原理

把你分支上的提交摘下来，逐个在新的基点上重放。内容相同，但每个提交的父提交变了，哈希也就全变了，本质是造了一批新提交。

使用场景

想让自己的分支历史保持一条直线，且这条分支还没被别人使用。

影响

改写历史。已推送、别人也在用的分支，绝对不要 rebase。

给智能体的提示词
我的分支 agent/<名> 还没推送过。请把它 rebase 到最新的 main 上。开始前先告诉我它领先 main 几个提交；遇到冲突暂停并解释，不要自行决定；完成后确认没有推送。

工作区暂存区本地仓库远程仓库

  • git cherry-pick <提交>复制这个提交的改动到当前分支
原理

取出某个提交引入的差异，在当前分支上生成一个内容相同的新提交（新哈希）。

使用场景

只想要另一条分支里的某一个修复，不想合并整条分支。

影响

当前分支新增提交；可能冲突。

给智能体的提示词
把提交 <哈希> 单独挑到当前分支。先用 git show 告诉我它改了什么，再执行；如果冲突，暂停告诉我。

工作区暂存区本地仓库远程仓库

  • git stash收起改动，工作区回到干净状态
  • git stash list看收了什么
  • git stash pop取回并删除记录
原理

把工作区和暂存区的未提交改动，保存成一个临时提交放进栈里，然后把工作区还原到最近提交。

使用场景

手上活没做完，但要紧急切去做别的事。

影响

改动暂时从工作区消失。别忘了取回，stash 里的东西很容易被遗忘。

给智能体的提示词
我要临时切换任务。先用 git stash push -m "<说明>" 收起未提交的改动，并告诉我 stash 的编号，再切换分支。之后提醒我回来时用 git stash pop 取回。

工作区暂存区本地仓库远程仓库

  • git restore <文件>丢弃工作区改动（无法恢复）
  • git restore --staged <文件>取消暂存，改动仍留在工作区
原理

用暂存区或最近提交里的版本，覆盖工作区（或暂存区）里的文件。

使用场景

改乱了想回到最近的干净状态；或者 add 错文件想撤回。

影响

丢弃工作区改动后，未提交的内容无法找回。

给智能体的提示词
我想撤销对 <文件> 的改动。先运行 git diff <文件> 给我看会丢掉什么，等我确认后再执行 git restore <文件>。只处理这一个文件。

工作区暂存区本地仓库远程仓库

  • git reset --soft HEAD~1撤销最近一次提交，改动留在暂存区
  • git reset HEAD~1撤销提交，改动留在工作区（默认 --mixed）
  • git reset --hard HEAD~1撤销提交并丢弃所有改动
原理

把当前分支指针往回挪。soft 只挪指针；mixed 连暂存区一起重置；hard 连工作区也一起重置，所以会丢数据。

使用场景

还没 push 的提交想重来。已经 push 的提交，请改用 revert。

影响

改写本地历史。hard 会丢失未提交的改动。

给智能体的提示词
我想撤销最近一次提交，但保留改动。请使用 git reset --soft HEAD~1，不要使用 --hard。执行前先确认这个提交没有 push 过，如果已经 push 了，先停下来告诉我。

工作区暂存区本地仓库远程仓库

  • git revert <提交>生成一个新提交，内容与旧提交相反
原理

不改历史，而是新增一个提交，把旧提交的改动反过来做一遍。历史里能清楚看到「做过、又撤销了」。

使用场景

已经 push 的提交出了问题，要撤销，又不能改写公共历史。

影响

历史只增不改，对协作者最安全。

给智能体的提示词
提交 <哈希> 已经推送到远程，需要撤销。请使用 git revert，不要 reset 或 force push。先告诉我这个提交改了什么、撤销后会影响哪些文件。

工作区暂存区本地仓库远程仓库

  • git reflog列出 HEAD 最近的每一次移动
  • git reset --hard <reflog 里的哈希>回到那个位置
原理

git 在本地悄悄记录 HEAD 每次移动的位置。就算你误用 reset 或删了分支，原来的提交通常还在，只是没有标签指着它。

使用场景

误操作后想找回。它是本地的，不会同步到远程，且过一段时间（默认约 90 天）会清理。

影响

只读；找回时的 reset 会改变当前状态。

给智能体的提示词
我刚才可能误操作丢了提交。先不要执行任何修改，只运行 git reflog，告诉我最近 15 次 HEAD 的移动，帮我找出误操作之前的那个位置，并给出恢复方案，等我确认再执行。

工作区暂存区本地仓库远程仓库

  • git worktree add ../wt-auth -b agent/auth新目录加新分支
  • git worktree list看有哪些工作间
  • git worktree remove ../wt-auth用完清理
原理

多个工作目录共用同一份 .git 对象库，各自检出不同分支。不需要重复克隆，也不会互相干扰。

使用场景

让多个智能体并行干活；或者你自己想一边审查一条分支，一边继续开发。

影响

新增目录；同一分支不能同时在两个工作间检出；依赖要各自安装。

给智能体的提示词
为并行任务创建 worktree：在 ../wt-<任务名> 新建目录，同时新建分支 agent/<任务名>，基于最新的 main。创建后告诉我路径，并提醒我需要在新目录里单独安装依赖。

工作区暂存区本地仓库远程仓库

  • git tag v1.0轻量标签
  • git tag -a v1.0 -m "信息"附注标签，带说明
  • git push origin v1.0标签需要单独推送
原理

和分支类似，都是指向提交的名字，但标签不会随新提交移动。

使用场景

发布版本、课程每一讲的代码定稿点。

影响

只加指针。

给智能体的提示词
给当前提交打附注标签 lesson-03，说明写「第三讲代码定稿」。先告诉我当前提交是哪一个，确认后再打，并说明推送标签需要单独的命令。

工作区暂存区本地仓库远程仓库

  • gh pr create用 GitHub CLI 在命令行开 PR（需安装 gh）
原理

PR 是 GitHub 的功能：把一条分支「申请」合并进另一条，让人和自动检查先审查。git 本身并没有 PR 这个概念。

使用场景

团队协作，或者你想在合并前有一个正式的审查记录和自动测试。

影响

在远程平台产生一条审查记录；合并后才会改变主分支。

给智能体的提示词
把分支 agent/<名> 推送到 origin，然后用 gh pr create 开一个 PR，目标分支 main。标题写清楚做了什么；正文用中文写：背景、改动点、如何测试、已知风险。

07 · 对话

怎么跟智能体说 git

你的角色是布置任务和审查结果，不是敲命令。下面这些话术，让智能体既高效又不越界。

万能公式：五块信息

目标要完成什么，一句话
范围可以改哪些文件或目录
边界不能碰什么，不能用什么命令
验收怎样算做完，跑什么测试
汇报做完后给我看什么
示例：把五块填满
目标：给课程 demo 的登录页加上错误提示。
范围：只改 src/login/ 目录和对应测试。
边界：新建分支 agent/login-error 再工作；不要动 main；不要 force push；不要提交 .env；不要改依赖。
验收：现有测试全部通过，并新增一条覆盖错误提示的测试。
汇报：完成后给我 git diff main...HEAD 的中文摘要，标出任何超出范围的改动，先不要 push。

口语对照：你说的话，它会用的命令

你说它大概会用你要留意
「存个档」add + commit只存在本地，还没上传
「传上去」push别人开始能看到了
「看看改了什么」status / diff只读，随便问
「回到昨天的样子」revert 或 reset是否已 push 决定用哪个
「先放一边，我要切任务」stash 或新分支问它放在哪，别丢了
「把那个分支并进来」merge要求先给 diff 摘要
「同步一下最新代码」fetch / pull先 fetch 看差异更稳

场景提示词库

开工前：先体检

每次开始新任务前，让智能体先摸清现场

提示词
开始之前先做检查，不要修改任何东西：1) git status 有没有未提交的改动；2) 当前分支和 origin 的差距；3) git log --oneline -5 最近提交。用中文汇报，然后问我今天要做什么。
开分支做一个小任务

一个任务一条分支，从最新的 main 出发

提示词
任务：<描述>。请先 git fetch，然后从最新的 origin/main 新建分支 agent/<任务名>。只在这条分支上改，范围限于 <目录>。完成后跑测试，给我 git diff main...HEAD 的中文摘要，先不要 push。
并行派三条线

配合 worktree 或云端线程使用

提示词
请把下面三件互不依赖的事分别放在独立分支和独立工作目录里并行处理：1) <任务A> 分支 agent/a；2) <任务B> 分支 agent/b；3) <任务C> 分支 agent/c。每条只改自己的范围，不能动别人的文件。全部完成后汇总一张表：分支、改了哪些文件、测试结果、风险。先不要合并。
审查智能体的成果

你的核心工作：看 diff，而不是看「它说做完了」

提示词
我要审查分支 agent/<名>。请给我：1) 相对 main 的改动文件清单；2) 每个文件改动的意图；3) 超出原定范围的改动；4) 删除、配置、依赖相关的改动；5) 你认为最该我细看的三处。用中文，不要修改代码。
合并一条分支

一次一条，先看后合，合完就测

提示词
我确认审查通过。请把 agent/<名> 合并到 main：先确认 main 是最新的；使用 merge；有冲突就暂停并解释；合并后运行测试；测试通过再告诉我，由我决定是否 push。
解决合并冲突

让它先讲清楚，再动手

提示词
合并出现冲突。请先不要修改：列出冲突文件；对每一处，解释当前分支和被合并分支各自想做什么；给出你建议的合并方式和理由。等我确认后再改，改完运行测试。
出事了：想撤销

先停手，让它诊断

提示词
先不要执行任何修改命令。请告诉我：1) 我想撤销的这个提交有没有 push 过；2) 它在哪些分支上；3) 最安全的撤销方式（已推送用 revert，未推送用 reset --soft），说明各自的影响。等我确认再执行。
收工：总结并推送

每天结束前的固定动作

提示词
收工检查：1) git status 确认没有遗漏和不该提交的文件；2) 汇总今天提交了什么；3) 推送当前分支到 origin（不用 force）；4) 用中文写一段 PR 描述：背景、改动、测试、风险。

写进项目说明里的 Git 规矩

放在仓库根目录的说明文件（比如 CLAUDE.md），编程智能体每次开工都会读。一次写好，所有会话都守规矩。

Git 规矩（可直接粘贴）
## Git 规矩
- 不直接在 main 上提交。每个任务新建分支，命名为 agent/<任务名>。
- 一个提交只做一件事，提交信息写清楚为什么改。
- 提交前先展示 git status 和 diff 摘要，等我确认后再 commit。
- 不提交 .env、密钥、大文件；发现要提交这类文件时先停下告诉我。
- 禁止 git push --force、git reset --hard、git clean -fd、git branch -D，除非我在当前对话中明确同意。
- 不 rebase 已经推送的分支。
- 遇到合并冲突，先解释两边各自的意图，再给方案，不要自行二选一。
- 每次收工用中文汇报：改了什么、为什么、还有什么风险。

红线：看到这些命令，先停一下

命令会发生什么更安全的替代
push --force用你的历史覆盖远程，别人的提交可能消失先 fetch，再 merge 或 rebase，正常 push
reset --hard丢弃所有未提交改动，且无法找回先 stash 或新开分支备份
clean -fd永久删除所有未跟踪文件先 clean -n 预览会删什么
restore . / checkout .丢弃工作区全部改动先 diff 看看，再单文件恢复
branch -D强删未合并的分支用 -d，未合并时它会拒绝
rebase 已推送分支改写公共历史，同事的分支会错位用 merge
--no-verify跳过提交前的检查修好检查失败的原因

学习模式：让智能体边做边教你

教学模式提示词
接下来所有 git 操作请用教学模式：每条命令执行前，先用一句话告诉我它会改变工作区、暂存区、本地仓库、远程仓库中的哪几个，再执行。执行后用一句话确认结果。遇到我可能没见过的术语，用生活类比解释一次。

08 · 救援

出事了怎么办

git 的历史几乎都能找回，关键是先停手、看清状态、再动手。所有救援的第一句话都是：先别动任何东西。

刚提交完，发现漏了文件或信息写错了（还没 push）

用 git commit --amend 把新改动合进上一个提交，或者只改提交信息。它会生成新提交、丢弃旧的，所以只适用于还没 push 的提交。

对智能体说
我刚提交，但漏了 <文件>。确认这个提交还没有 push 后，把该文件加入并用 git commit --amend 合并进上一次提交，提交信息保持不变。
提交到了错误的分支（还没 push）

不要慌。提交本身还在，只是站错了位置。思路是：在当前位置新建一条分支保住这些提交，再让原分支退回去。这里涉及 reset，务必让智能体先讲方案。

对智能体说
我把提交做在了 main 上，本来应该在新分支。先不要动任何东西：告诉我这些提交的哈希，并给出方案：新建分支 agent/<名> 保存它们，再把 main 恢复到 origin/main。说明每一步的影响，等我确认。
已经 push 的提交想撤销

用 git revert，生成一个反向提交。历史里会留下「做过又撤销」的记录，但对协作者最安全。不要 reset 再 force push。

对智能体说
提交 <哈希> 已经在远程了，请用 git revert 撤销它。不要 reset，不要 force push。先告诉我撤销后会改变哪些文件。
误用了 reset --hard，或者误删了分支

git reflog 是救命稻草：找到出事之前 HEAD 所在的哈希，再回到那里。注意：从未提交过的工作区改动，reflog 也救不回来，因为它们从没被记录。

对智能体说
我可能误操作丢了东西。先只运行 git reflog，告诉我最近 20 次 HEAD 移动，帮我判断哪一条是出事之前的位置。给出恢复方案并等我确认。
合并冲突了

打开冲突文件，会看到 <<<<<<<、=======、>>>>>>> 三种标记。删掉标记，保留正确内容，然后 git add 和 git commit。想放弃：git merge --abort。

对智能体说
合并冲突了。先不要改文件：列出冲突文件，逐处解释两边意图，给出建议方案。我确认后你再修改，修改后运行测试，再完成合并提交。
push 被拒绝（rejected）

这是 git 在保护你：远程有你本地没有的提交。正确做法是先 fetch 看差异，再 merge 或 rebase，然后重新 push。不要用 --force 硬推。

对智能体说
push 被拒绝了。请先 git fetch，告诉我远程多了哪些提交、改了哪些文件，再给出合并方案。不允许使用 force。
不小心把密钥提交了

第一步是让密钥失效（去对应平台重新生成），这比清理历史重要得多。只是删除文件是不够的，历史里仍然有那一版。历史清理是复杂操作，先作废、再评估。

对智能体说
我可能把密钥提交进了仓库。先不要修改任何东西：找出是哪个文件、哪个提交、有没有 push 过。告诉我我需要在哪个平台作废这个密钥，再提出清理历史的方案供我评估。
detached HEAD（游离状态）

你站在一个没有分支的提交上。想保留这里的提交：git switch -c 新分支名。不想要：git switch main 回去。

对智能体说
git 提示 detached HEAD。请告诉我我现在在哪个提交、有没有未保存的新提交，并给出两个选项：保留成新分支，或回到 main。等我选择。
手上的活没做完，要临时换任务

用 git stash 收起改动，切走处理完，再 git stash pop 取回。或者更稳妥：在当前分支做个临时提交，之后再整理。

对智能体说
我要临时切去处理别的任务。请把当前未提交的改动 stash 起来并命名，告诉我编号，然后再切换分支。