# git-learning

**Repository Path**: carter65536/git-learning

## Basic Information

- **Project Name**: git-learning
- **Description**: ai 时代下了解比操作更重要
- **Primary Language**: Unknown
- **License**: MIT
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2026-10-20
- **Last Updated**: 2026-11-10

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# Git 学习大纲（分级）

按「能力等级」划分的 Git 学习路线：从**能干活不闯祸**，到**理解 Git 是什么、能改造它**。

不分 100 天。Git 的知识量撑不起 100 天，硬凑只会把 30 天能懂的东西拖成三个月。
这里按 **5 个等级**划分，每一级的判定标准有两条，**两条都要过**：

1. **知道（主口径）** —— 能用**自己的话**说清：这个操作是什么、动了什么、做错了会怎样；能让 AI 替你做完，并且看得出 AI 做错或做危险了。
2. **手感（底线）** —— 这一级列出的操作，**每条至少亲手敲过一次**，知道报错长什么样。

为什么第一条是主口径：AI 时代真正会出事的，不是「你手打得不熟」，而是「你不知道有这么一步，也不知道它的后果」。所以**知道比精通重要** —— 但「亲手碰过」是能判断 AI 干得对不对的前提，第二条不能省。

## 怎么用这份大纲

- 从上往下走，**不要跳级**。L3 的排障能力建立在 L1 就对三个区有清楚认识的基础上。
- 每级末尾有「验收」，**过不了就停在这一级**，别往下一级堆知识。
- 每一级配了参考资料定位（Pro Git 章节 / learnGitBranching 关卡 / git-flight-rules 小节）。
- 每完成一级，在本仓库对应目录里留下一份自己的笔记（见文末「进度怎么记」）。
- **每个知识点都拆成三条路线**：
  1. **手打命令行** —— 原样命令是什么，它到底动了什么
  2. **IDE（VSCode）** —— 图形界面在哪点，点下去等价于哪条命令
  3. **与 AI 协作** —— 怎么把需求说清楚让 AI 做，给 AI 立的规矩（规则文件）怎么写

  三条都过一眼，平时用顺手的，但**三条都要知道** —— 这正是「知道 > 精通」的落点。详细写法见 [L0-survival.md](L0-survival.md)（后面各级照这个结构）。

---

## L0 · 生存级：能干活，不闯祸

**目标**：能把文件提交上去、能把别人的仓库拉下来。此时还谈不上协作，只是"能用"。

- [ ] 理解 Git 的三个区：**工作区（working tree）→ 暂存区（index / staging）→ 版本库（repository）**
- [ ] 理解 commit 是"整个项目的快照 + 指向父提交的指针"，不是"文件的差异"
- [ ] `git status` —— 看清当前谁改了、改的东西在哪个区
- [ ] `git diff` / `git diff --staged`（旧写法 `--cached`）—— 分清"没暂存的改动"和"已暂存的改动"
- [ ] `git add <文件>` / `git add .` —— 把改动放进暂存区
- [ ] `git commit -m "<说明>"` —— 把暂存区做成一个快照
- [ ] `git log --oneline` —— 看提交历史
- [ ] `git init` —— 把当前目录变成仓库（和 `clone` 是两条入口，clone 下来的不用再 init）
- [ ] `git clone <url>` —— 把远程仓库整个拿下来｜`git remote -v` —— 看它连的是哪个远程
- [ ] `git pull` / `git push` —— 拉取和推送
- [ ] `.gitignore` —— 知道哪些东西不该进版本库（编译产物、编辑器配置、密钥）｜`git rm --cached <文件>` —— 已跟踪的文件改成不再跟踪（磁盘上保留）
- [ ] 知道 `HEAD` 是一个"你现在在哪"的指针

**验收（手艺）**：在一个空目录里 `git init`，建 3 个文件、分 2 次提交、`git log` 能看到 2 条记录，并能说出每一次提交时暂存区里有什么。

**验收（知道）**：不看笔记说清「工作区 / 暂存区 / 版本库 + HEAD」在一次提交里各发生了什么；给 AI 一段提示词让它按你指定的格式写提交信息，**一次就对上**；有人让你敲 `git reset --hard` 时，能立刻说出它会丢什么、该先做什么兜底。第 3 条最关键 —— L0 的全部意义就是**在别人（和 AI）让你闯祸之前，知道那是祸**。

（这一级三条路线的详细写法见 [L0-survival.md](L0-survival.md)）

**对应资料**：Pro Git `ch01` + `ch02`｜learnGitBranching 基础关（`commits`、`staging`）｜VSCode 官方文档 Source Control 一节

---

## L1 · 日常级：一个人干活顺了，开始和人协作

**目标**：能开分支、能合并、能处理冲突、能在搞错的时候退回来。

- [ ] `git branch` / `git switch -c <分支>` / `git switch <分支>` —— 建分支、切分支
- [ ] **理解分支只是一张写着某个提交哈希的便利贴**，不是目录副本
- [ ] `git merge <分支>` —— 合并；分清 **快进（fast-forward）** 和 **三方合并（产生 merge commit）**
- [ ] `git merge --no-ff <分支>` —— 强制产生一个 merge commit（**不走快进**），保住「这里合并过一个分支」的历史
- [ ] `git branch -d` / `-D` —— 删除已合并 / 未合并的分支
- [ ] `git branch -m <新名>` —— 给分支改名｜`git push origin --delete <分支>` —— 删远程分支
- [ ] `git branch -r` / `git branch -a` —— 看远程分支 / 看全部（本地 + 远程）；`origin/main` 这种叫**远程跟踪分支**
- [ ] `git remote -v` / `git remote add` / `git push -u origin <分支>`
- [ ] `git remote add upstream <原仓库地址>` / `git fetch upstream` / `git merge upstream/main` —— **fork 之后同步上游**；`origin` 是你自己的 fork，`upstream` 是原仓库
- [ ] `gh pr create`（或网页上的 New pull request）—— 发起 PR；知道 **merge commit / squash / rebase** 三种合并方式在历史里各长什么样（由仓库设置决定）
- [ ] **理解 fork 是服务端复制、PR 是平台上的请求** —— 两者都不是 Git 命令
- [ ] **分清 `git fetch` 和 `git pull`**：`pull = fetch + merge`
- [ ] `git log --oneline --graph --all --decorate` —— 把分支结构看成一张图
- [ ] `git show <提交>` / `git blame <文件>` —— 看某次改动 / 看某一行是谁写的
- [ ] `git diff HEAD` —— **工作区 vs 版本库**（L0 已讲另两种：工作区↔暂存、暂存↔版本库）；三种对比凑齐
- [ ] **撤销三件套，必须分清**：
  - [ ] `git restore <文件>` —— 丢弃工作区改动（危险：改动直接没了）
  - [ ] `git restore --staged <文件>` —— 把文件从暂存区拿出来，改动仍在工作区
  - [ ] `git revert <提交>` —— **新建一个提交**来抵消旧提交（安全，历史保留）
- [ ] `git reset --soft / --mixed / --hard <提交>` —— 知道三者的区别是"分别动 HEAD / index / worktree 中的哪几个"
- [ ] **`git revert` vs `git reset`，必须分清**（最容易搞混、后果最重的一对）：

  | 对比项 | `git revert <提交>` | `git reset <提交>` |
  | --- | --- | --- |
  | 干了什么 | **新建一个提交**去抵消旧提交 | **移动分支指针**，把历史倒回去 |
  | 历史 | **保留**，只多了一条「反向」提交 | **被改写**：退掉的提交从分支上消失 |
  | 哈希 | 旧提交原样不动 | 后面的提交**全部换哈希** |
  | 已推送过 | **安全**，直接能用 | **危险** —— 除非这分支只有你一个人用 |
  | 会丢东西吗 | 不丢 | `--hard` 会丢工作区改动 |
  | 一句话 | 「历史别动，只想抵消它」 | 「我要把历史倒回去」 |

  **记一条就够**：**已经 push 过的提交一律用 `revert`；没 push、只有你自己，才考虑 `reset`。**
- [ ] `git stash` / `git stash list` —— 临时把改动收起来（**真实用途：切分支前先把没写完的改动收好**，否则工作区不干净，Git 不让你切）
  - [ ] `git stash -u` —— **连未跟踪的新文件一起收**。不加 `-u` 时新建的文件留在原地，切分支照样被拦
  - [ ] `git stash pop` / `git stash apply` —— 取回来。`pop` **会删掉**这条记录，`apply` **保留**；多个 stash 时用 `stash@{1}` 指定取哪一条
  - [ ] `git stash drop <stash@{n}>` —— 删掉某一条｜`git stash clear` —— 全清
- [ ] **解决冲突**：读懂 `<<<<<<<` / `=======` / `>>>>>>>` 三个标记，手工改完 → `git add` → `git commit`
- [ ] `git config --global user.name "..."` / `user.email "..."`｜`git config -l` —— 配完查看配成功没
- [ ] `git alias` —— 给自己配缩写（`git config --global alias.lg "log --oneline --graph --all"`）；写文档、贴命令时一律用全称
- [ ] 配置 SSH 密钥，知道 SSH 和 HTTPS 两种远程地址的差别
- [ ] `.gitattributes` —— **把换行策略写进仓库**（`* text=auto`、`*.sh text eol=lf`），别靠每人本机的 `core.autocrlf`｜`git check-attr -a <文件>` 验证命中了哪条规则

**验收（手艺）**：独立走完一次完整流程——`fork → clone → 建分支 → 改 → commit → push → 提 PR`；并且制造一次冲突并手工解决掉；把误改的文件恢复原样。

**验收（知道）**：说清「分支只是一张贴在某提交上的便利贴」（不是目录副本）、`fetch` 和 `pull` 差在哪、`restore` 三件套各丢什么；让 AI 制造一次冲突并给你三条可选解法，你能判断哪条最安全、哪条会丢东西。

**练习与范例**（按 L0 的模子）：三条路线各一份作业 —— `L1-practice/cli/exercises.md`、`L1-practice/ide/exercises.md`、`L1-practice/ai/exercises.md`；难懂命令单独写范例 —— `L1-examples/log-graph.md`（读懂分支图）、`L1-examples/merge-conflict.md`（冲突标记解读）、`L1-examples/undo.md`（撤销三件套）、`L1-examples/stash.md`（`-u` 与 `pop` / `apply`）。

**对应资料**：Pro Git `ch02` `ch03` `ch04`｜learnGitBranching `branching` / `merging` / `remote` / `restore` 关｜git-flight-rules「暂存」「未暂存」「分支」三节｜opensource.guide 的 CONTRIBUTING / PR 规范

---

## L2 · 整洁级：提交历史开始有人看得懂

**目标**：从"能提交"到"提交得让人愿意看"。这一步是业余和职业的分水岭。

- [ ] **相对引用**（下面的 rebase 会用到）：`HEAD~<n>` 往上数第 n 个父提交｜`HEAD^` 上一个父提交（合并提交用 `HEAD^2` 取第 2 个父）｜`HEAD@{<n>}` reflog 里的第 n 步
- [ ] `git rebase <基准分支>` —— 把本地提交"搬"到最新主干上，换来一条直线
- [ ] `git rebase --onto <新基> <旧基> <分支>` —— 只把「旧基之后」的一段搬到新基上（分支从错误的底座切出来时用）
- [ ] **明白 rebase 和 merge 的区别**：rebase 是改写历史（哈希会变），merge 是新增一个提交
- [ ] `git rebase -i HEAD~<n>` 交互式 rebase，掌握 6 个动作：
  - [ ] `pick` 保留｜`reword` 只改提交信息｜`edit` **停下来改内容，再 `--continue`**｜`squash` 合并进上一个（保留信息）｜`fixup` 合并进上一个（丢弃信息）｜`drop` 删掉
  - [ ] 调整提交顺序、把 5 个零碎提交压成 1 个
- [ ] `git cherry-pick <提交>` —— 只把某一个提交"摘"到当前分支（另有 `-n` 只暂存不提交）
- [ ] `git cherry-pick <A>..<B>` —— 一次摘一个区间（A 不含、B 含；要连 A 一起用 `A^..B`）
- [ ] **rebase 之后要推，得用 `--force-with-lease`** —— 历史被改写，普通 `push` 会被拒；裸 `--force` 会覆盖同事刚推的提交（两种写法的差别在本级分组 4）
- [ ] `git cherry-pick -x <提交>` —— 在提交信息里**记下原提交哈希**（方便溯源）
- [ ] `git add -p` —— **分块暂存**：一个文件里的改动分开提交
- [ ] `git commit --amend` —— 补进上一次提交 / 只改提交信息
- [ ] `git commit --allow-empty -m "..."` —— 造一个空 diff 的真提交（打点 / 触发 CI）
- [ ] `git tag -a <标签> -m "..."` / `git push --tags` —— 打版本标签（附注标签：带作者、日期，推荐）
- [ ] **标签补充**：`git tag <标签>` 轻量标签（只是个指针，不带信息）｜`git tag` 列全部｜`git push origin <标签>` 推单个｜删：`git tag -d` + `git push origin --delete <标签>`
- [ ] **搜索历史**：`git log -S"<字符串>"`（某段内容什么时候被加进来的）／`git log -G"<正则>"`
- [ ] **筛选历史**：`git log -n <条数>`｜`--author=<人>`｜`--since=<日期>`｜`--grep=<关键词>`（按提交信息找）
- [ ] `git log -p <文件>` / `git log --follow <文件>` —— 追一个文件的完整演变
- [ ] `.mailmap` —— 同一人的多个名字 / 邮箱归并显示（`git shortlog -sne`、`git blame` 都读它），只改显示不改提交
- [ ] `.git-blame-ignore-revs` —— 让 `git blame --ignore-revs-file` 跳过纯格式化提交，追溯不被一次美化冲掉
- [ ] `.gitmessage` + `git config commit.template` —— 提交信息模板（`-m` 时不生效，一字不改直接退出会被拒）
- [ ] 分得清 `A..B`（在 B 不在 A）和 `A...B`（两者的差异）

**验收（手艺）**：把一个分支上 5 个零碎提交整理成 1~2 个信息清晰的提交；把 A 分支的一个提交精确摘到 B 分支；在提交前用 `add -p` 把一个文件里两类改动分开提交。

**验收（知道）**：说清 `rebase` 和 `merge` 的本质差别（改写历史 vs 新增提交）、为什么 rebase 之后哈希全变；让 AI 帮你出一版提交历史整理方案，你能**提前指出**「哪些提交已经被推送过、动它会祸害同事」。

**练习与范例**（按 L0 的模子）：三条路线各一份作业 —— `L2-practice/cli/exercises.md`、`L2-practice/ide/exercises.md`、`L2-practice/ai/exercises.md`；难懂命令单独写范例 —— `L2-examples/rebase-i.md`（交互式 rebase 全流程）、`L2-examples/range.md`（`A..B` vs `A...B`）。

**对应资料**：Pro Git `ch03` + `ch07`（重写历史）｜learnGitBranching `relativeRefs` / `cherryPick` / `interactiveRebase` / `manyRebases` / `selectiveRebase` / `jugglingCommits` / `grabbingOneCommit` / `tags` 关｜git-flight-rules「编辑提交」节

---

## L3 · 排障级：出事能救回来

**目标**：别人慌的时候你不慌。这一级学的是"不可逆操作"的边界，以及越界之后怎么回来。

- [ ] **`git reflog` —— 最高优先级，救命稻草**
  - [ ] 原理：Git 记录了 HEAD 和分支每一次移动，即使提交/分支"没了"，只要没被 GC 就找得回来
  - [ ] 场景：误 `reset --hard`、误删分支、误 rebase 之后完整找回
  - [ ] ⚠️ **边界**：对象一旦被 GC 就真没了 —— `git gc --prune=now` 立即删、默认约 90 天后自动清，届时 `reflog` 也救不回（详见 L4「打包与压缩」）
- [ ] `git reset` 三种模式的**本质**（L1 只学了「怎么用 + 哪个危险」，这里补「为什么」）：各自对 HEAD / index / worktree 动没动，为什么 `--hard` 会丢工作区改动
- [ ] 找回悬空对象：`git fsck --lost-found`、`git fsck --unreachable`，配合 `git cherry-pick` 恢复
- [ ] `git bisect start / good / bad / run / reset` —— 二分定位"是哪个提交引入了 bug"
  - [ ] `git bisect run <脚本>` 的契约：脚本返回 **0=good｜1~127=bad｜125=skip** —— 不说清这个，`run` 根本用不起来
- [ ] 冲突进阶：
  - [ ] `git merge --abort` / `git rebase --abort` / `--skip` / `--continue` —— 每个阶段都有退路
  - [ ] 策略参数 `-X ours` / `-X theirs` —— 合并**策略**（决定整体怎么合）
  - [ ] `git checkout --ours <文件>` / `--theirs <文件>` —— 冲突**文件**取哪一边（和上面那个策略参数别混为一谈）
  - [ ] `git rerere` —— 记住冲突解法，同一冲突不重复解第二遍（**默认是关的**，要先 `git config rerere.enabled true`）
- [ ] `git clean -n` —— **试运行：先看会删掉什么**（最重要的一条安全习惯）｜`git clean -fd` —— 删未跟踪的文件和目录
- [ ] **危险操作清单，知道每个的后果与正确姿势**：
  - [ ] `git reset --hard` —— 丢工作区，先 `stash` 或 `reflog` 兜底
  - [ ] `git restore .` / `git checkout .` —— **批量丢工作区改动**；名字里没有 hard，比 `reset --hard` 更隐蔽
  - [ ] `git stash clear` —— 清空全部 stash（丢了同样只能靠 `reflog` 兜底）
  - [ ] `git clean -fdx` —— 删未跟踪文件，`-x` 连 `.gitignore` 里的一起删
  - [ ] `git push --force` —— **一律改用 `--force-with-lease`**，避免覆盖同事刚推的提交

**验收（手艺）**：制造一次 `reset --hard` 灾难，靠 `reflog` 在 3 分钟内完整找回；用 `bisect` 在 20 个提交里定位到出错的那一个；能解释为什么团队里禁止裸 `push --force`。

**验收（知道）**：出事时第一反应能想到「`reflog` 能不能救」；能列出 L0~L2 学过的每一条「会丢数据的命令」及其后果；AI 给你一条 `--hard` / `--force` 的操作建议时，你能**先要求它说明「丢什么、怎么兜底」再决定跑不跑**。

**练习与范例**（按 L0 的模子）：三条路线各一份作业 —— `L3-practice/cli/exercises.md`、`L3-practice/ide/exercises.md`、`L3-practice/ai/exercises.md`；难懂命令单独写范例 —— `L3-examples/reflog.md`（三步救回）、`L3-examples/bisect.md`（二分定位全流程）。

**对应资料**：Pro Git `ch07`（reset 详解）+ `ch10` 引用部分｜learnGitBranching `detachedHead` / `reversingChanges` / `multipleParents` 关｜git-flight-rules「我意外做了一次硬重置」等节

---

## L4 · 掌控级：理解 Git 是什么，能改造它

**目标**：不再"使用工具"，而是"知道工具底下发生了什么"，并能按自己的需要定制它。

- [ ] **对象模型**（Git 的全部就是 4 类对象）：
  - [ ] `blob`（文件内容）｜`tree`（目录）｜`commit`（快照 + 父指针 + 作者信息）｜`tag`（带注解的标签）
  - [ ] **内容寻址**：对象名 = 内容的 SHA 哈希，内容一样则对象一样
- [ ] **底层命令（plumbing）**，用它手工造一个提交：
  - [ ] `git hash-object -w` → `git write-tree` → `git commit-tree` → `git update-ref`
  - [ ] `git cat-file -t / -p <对象>` 查看对象类型和内容｜`git ls-tree <tree>`
  - [ ] `git rev-parse <引用>` —— 把 `HEAD` 这类引用解析成哈希；`git rev-list <范围>` —— 列出范围内的提交（写脚本几乎必用）
  - [ ] 做完这一步，你就彻底明白 `git commit` 那一条命令底下干了什么
- [ ] **引用体系**：`refs/heads/`（本地分支）、`refs/remotes/`（远程跟踪分支）、`refs/tags/`（标签）、`packed-refs`
- [ ] **detached HEAD 的本质**：HEAD 不指向分支而直接指向某个提交，此时提交没人认领（要靠 reflog 找）
- [ ] `git symbolic-ref` —— HEAD 到底是什么
- [ ] **打包与压缩**：packfile、delta 压缩、`git gc` / `git repack` / `git count-objects -v` / `git prune`
  - [ ] ⚠️ **回接 L3**：`git gc --prune=now` 会把 reflog 里的老对象真删掉 —— 到这一步，`reflog` 也救不回来了
- [ ] **钩子 hooks**（`client` 侧 / `server` 侧）：
  - [ ] `pre-commit`（提交前跑检查）｜`commit-msg`（校验提交信息格式）｜`pre-push`（推送前跑测试）
  - [ ] `core.hooksPath` —— 统一管理钩子目录；**`.git/hooks/` 默认不进版本控制**，团队要共享钩子就得靠它指向仓库内的目录
- [ ] **重写历史**：
  - [ ] `git filter-repo`（官方已推荐它取代 `filter-branch`）—— 从**全部历史**里抹掉一个大文件 / 泄漏的密钥，给仓库瘦身
  - [ ] ⚠️ **它不是 Git 自带**，要单独安装（pip / 包管理器）；本机是 DLP + Python 环境，装之前先想清楚怎么卸干净
  - [ ] 知道 `filter-branch` 已被弃用、为什么危险
- [ ] **换行与属性的进阶**（转换方向、`* text=auto` / `*.sh eol=lf` 等基础规则 L1 已讲，这里只补仓库级定制）：
  - [ ] `.gitattributes` 的进阶规则：`binary`（不碰）、`merge=union`（冲突自动并集）
  - [ ] `core.autocrlf` 与仓库内 `.gitattributes` 冲突时，以**仓库内规则**为准
  - [ ] 复习分工：`.gitignore` 管**要不要跟踪**，`.gitattributes` 管**怎么处理**
- [ ] **并行与复用**：`git worktree add / list / remove` —— 一个仓库同时检出多条分支到不同目录；子模块 `git submodule add` / `update --init --recursive` / `foreach` —— 知道它只存指针、默认停在父仓库记录的提交上
- [ ] **大仓库优化**：`sparse-checkout`（只检出部分目录）、`--filter=blob:none` 部分克隆、`git maintenance`
- [ ] `git update-index --skip-worktree <文件>` / `--assume-unchanged` —— 本地改了配置 / 环境文件，又不想提交上去
- [ ] **凭据与大文件**：`credential.helper`、Git LFS（大文件）—— SSH / HTTPS 两种地址的差别见 L1

**验收（手艺）**：不敲 `git commit`，用手工底层命令造出一个能通过 `git log` 的提交；写一个 `commit-msg` 钩子拦住不符合格式的提交信息；用一个已推送的大文件做练习，把它从全历史里安全抹除并把仓库瘦下来。

**验收（知道）**：说清「对象名 = 内容哈希」意味着什么（为什么内容一样对象就一样、为什么改了历史哈希全变）；能逐句判断 AI 给的一段底层命令（`hash-object → write-tree → commit-tree → update-ref`）每一步在造什么；能解释 `filter-repo` 为什么必须配强制推送、动手前该先和团队做什么沟通。

**练习与范例**（按 L0 的模子）：三条路线各一份作业 —— `L4-practice/cli/exercises.md`、`L4-practice/ide/exercises.md`、`L4-practice/ai/exercises.md`；难懂命令单独写范例 —— `L4-examples/plumbing.md`（`hash-object → write-tree → commit-tree → update-ref` 手工造提交）。

**对应资料**：Pro Git `ch08`（自定义 Git）+ `ch10`（Git 内部原理）｜learnGitBranching 无对应关卡（这级已经超出它的范围）

---

## 参考资料对照表

| 等级 | Pro Git（`progit2-zh`） | learnGitBranching 关卡 | git-flight-rules | opensource.guide |
| --- | --- | --- | --- | --- |
| L0 生存级 | `ch01` 起步、`ch02` 基础 | `commits`、`staging` | —— | —— |
| L1 日常级 | `ch02` `ch03` `ch04` `ch06`（贡献流程） | `branching`、`merging`、`remote`、`restore` | 暂存 / 未暂存 / 分支 | CONTRIBUTING、PR 规范 |
| L2 整洁级 | `ch03`、`ch07` 工具 | `relativeRefs`、`cherryPick`、`interactiveRebase`、`manyRebases`、`jugglingCommits`、`tags` | 编辑提交 | —— |
| L3 排障级 | `ch07`、`ch10`（引用） | `detachedHead`、`reversingChanges`、`multipleParents` | 硬重置 / 推错分支 | —— |
| L4 掌控级 | `ch08`、`ch10` 内部原理 | 无 | —— | —— |

---

## 进度怎么记

建议在本仓库里按等级建目录，每级一个文件，只写**自己的话**：

```
git-learning/
├── README.md              # 本文件：路线图与入口
├── L0-survival.md         # 三条路线（命令行 / IDE / AI）+ 我的笔记 + 踩坑记录 + 验收结果
├── L0-practice/           # L0 验收作业：按三条路线分目录
│   ├── cli/exercises.md   # 命令行路线（手艺底线）
│   ├── ide/exercises.md   # IDE 路线
│   └── ai/exercises.md    # AI 路线
├── L0-examples/           # L0 范例：难懂的命令单独讲透
│   └── check-ignore.md    # git check-ignore -v（超出 L0，但有用）
├── L1-daily.md            # L1 三条路线（命令行 / IDE / AI）+ 我的笔记 + 踩坑记录 + 验收结果
├── L1-practice/           # L1 验收作业：按三条路线分目录
│   ├── cli/exercises.md   # 命令行路线（手艺底线）
│   ├── ide/exercises.md   # IDE 路线
│   └── ai/exercises.md    # AI 路线
├── L1-examples/           # L1 范例：难懂的命令单独讲透
│   ├── log-graph.md       # git log --graph 分支图怎么读
│   ├── merge-conflict.md  # 冲突标记解读 + 手工解决全流程
│   ├── undo.md            # restore / revert / reset 撤销三件套
│   └── stash.md           # stash 的 -u 与 pop / apply 区别
├── L2-tidy.md             # L2 三条路线（命令行 / IDE / AI）+ 我的笔记 + 踩坑记录 + 验收结果
├── L2-practice/           # L2 验收作业：按三条路线分目录
│   ├── cli/exercises.md   # 命令行路线（手艺底线）
│   ├── ide/exercises.md   # IDE 路线
│   └── ai/exercises.md    # AI 路线
├── L2-examples/           # L2 范例：难懂的命令单独讲透
│   ├── archive.md         # git archive 导出某个版本的文件树
│   ├── rebase-i.md        # 交互式 rebase 六个动作全流程
│   └── range.md           # A..B 与 A...B 的区别
├── L3-rescue.md           # L3 三条路线（命令行 / IDE / AI）+ 我的笔记 + 踩坑记录 + 验收结果
├── L3-practice/           # L3 验收作业：按三条路线分目录
│   ├── cli/exercises.md   # 命令行路线（手艺底线）
│   ├── ide/exercises.md   # IDE 路线（重点是「哪些 IDE 做不了、必须开终端」）
│   └── ai/exercises.md    # AI 路线（重点是「让 AI 先给兜底方案」）
├── L3-examples/           # L3 范例：难懂的命令单独讲透
│   ├── reflog.md          # 三步救援：怎么从一堆 HEAD@{n} 里挑对那一格
│   └── bisect.md          # 二分定位全流程（手动 + run）
├── L4-mastery.md          # L4 三条路线（命令行 / IDE / AI）+ 我的笔记 + 踩坑记录 + 验收结果
├── L4-practice/           # L4 验收作业：按三条路线分目录
│   ├── cli/exercises.md   # 命令行路线（手艺底线：手工造提交 / gc / hooks）
│   ├── ide/exercises.md   # IDE 路线（重点是「哪些事 IDE 不该做」）
│   └── ai/exercises.md    # AI 路线（重点是「让它解释机制，别让它动仓库」）
└── L4-examples/           # L4 范例：难懂的命令单独讲透
    └── plumbing.md        # hash-object → write-tree → commit-tree → update-ref 手工造提交
```

每份笔记里固定四块：

1. **我做了什么** —— 实际敲过的命令，附当时的输出（尤其是报错）
2. **我当时不懂什么** —— 卡住的地方，写清楚卡在哪一步
3. **三条路线对照** —— 同一个功能，命令行 / IDE / AI 各是怎么做的，哪条最顺手，给 AI 立的规矩有没有管住它
4. **一句话总结** —— 这一级最核心的那条认知，用你自己的话写

第 4 条最关键。**能用自己的话把一件事讲清楚，才算真懂了**——笔记里全是复制粘贴的命令清单，等于没写。

---

## 本教程没覆盖的命令

先说明白：L0 ~ L4 覆盖的是**日常与救命的骨架**，不是 Git 的全部。`git help -a` 列出的子命令有上百个，本教程只挑了高频的六七十个。

**没覆盖 ≠ 不重要，只是"这个场景你现在还没撞上"**。下面按场景列出来，遇到时知道去哪儿查就行。

| 场景 | 本教程没碰的命令 | 为什么没讲 |
| --- | --- | --- |
| 查询与统计 | `git grep`、`git shortlog`、`git describe`、`git name-rev` | 不是生存必需；要搜历史代码、生成版本名时再学 |
| 邮件 / 补丁工作流 | `git format-patch`、`git am`、`git send-email`、`git request-pull`、`git apply` | 内核、邮件列表式协作才用；GitHub PR 走不到这条路 |
| 冲突与对比进阶 | `git rerere`、`git merge-tree`、`git range-diff` | 自动化解决重复冲突、比较两版补丁；遇到再学 |
| 传输与镜像 | `git bundle`、`git ls-remote`、`git remote show` / `prune`、`git fetch --prune` | 离线搬运仓库、清理失效远程分支时才会用到 |
| 服务端 / 其它 VCS | `git daemon`、`git http-backend`、`git instaweb`、`git svn`、`git p4`、`git fast-import` / `fast-export` | 运维搭服务、从 SVN/P4 迁移专用 |
| 底层对象补充 | `git read-tree`、`git checkout-index`、`git pack-objects`、`git index-pack`、`git verify-pack`、`git mktree`、`git var`、`git stripspace` | L4 只挑了"手工造提交"必需的那几个，其余知道存在即可 |
| 维护与诊断 | `git commit-graph`、`git multi-pack-index`、`git bugreport`、`git diagnose`、`git verify-commit` / `verify-tag` | 仓库大到一定程度、或者要报 bug 时才用 |
| 很少用 / 已弃用 | `git notes`、`git replace`、`git filter-branch`、`git whatchanged` | 有更稳的替代（`filter-repo`、`switch` / `restore`）；知道它存在、为什么被替代就够 |

还有一类**不是新命令、只是已有命令的模式**，同样没全部展开：

- `git fetch --prune`、`git push --tags / --all / --delete`
- `git tag -d`、`git tag -v`
- `git diff --stat / --name-only / --word-diff`
- `git log --author`、`--since`、`--grep`、`-p`、`--follow`
- `git config --global / --local / --unset / --list`
- `git stash push -m`、`git stash branch`

---

## 没覆盖的命令怎么自学

命令是查不完的，**方法只有一条：先搞清"我要干什么"，再让 `git help` 告诉你，最后在小仓库里验证**。

### 第一步：找到命令

```bash
git help -a          # 列出所有子命令（一屏屏翻，q 退出）
git help -g          # 按主题列指南（revisions、workflows、attributes……）
git help -a | grep <关键词>   # 比如 grep stash / grep remote
```

发现自己连"该用哪个子命令"都不知道时，先用一句话描述需求，再让 AI 给 2~3 个候选命令 —— **但只把它当索引，不当结论**。

### 第二步：`git help` 读三块就够

```bash
git help <命令>       # 完整手册（等同 man git-<命令>）
git <命令> --help     # 同上
git <命令> -h         # 只打用法摘要，最快
git help -c           # 列出所有配置项（找 core.* / merge.* 时用）
```

手册很长，**别从头读**，只读三块：

1. `DESCRIPTION` —— 这个命令到底干什么
2. `OPTIONS` —— 你要用的那个参数，以及它的默认值
3. `EXAMPLES` —— 直接抄一个最接近你场景的，改路径

看到 `--force`、`--hard`、`--prune`、`--no-verify` 这类词，**先去 OPTIONS 里确认它删什么、跳什么**，再动手。

### 第三步：在一次性仓库里验证

不要拿真实仓库试新命令。固定用这个模板：

```bash
rm -rf /tmp/git-lab && mkdir -p /tmp/git-lab && cd /tmp/git-lab
git init -q -b main
git config user.name test && git config user.email test@example.com
printf 'a\n' > a.txt && git add a.txt && git commit -qm "feat: a"
# 在这里跑你想验证的命令
```

验证时守三条：

- **先 dry-run**：能加 `-n` / `--dry-run` 的，先看清单（`clean -n`、`prune --dry-run`、`push --dry-run`）。
- **前后各看一眼**：`git status -sb`、`git log --oneline -3`、`git diff`。
- **留下真输出**：把命令和输出一起贴进笔记；对不上就重跑，别凭印象写。

### 第四步：AI 只做"解释器"，你做"验证者"

提示词模板：

> 我要做 <一句话目标>，环境是 <仓库状态>。请先告诉我该用哪个 Git 命令，再列出：① 它会改哪些东西 ② 有没有不可逆风险 ③ 怎么验证成功。**先不要执行**。我会在 /tmp 的一次性仓库里自己跑。

AI 给完，按第三步验证；输出看不懂就贴回去让它逐行解释，但**最终以你亲手跑出来的结果为准**。这套流程和 L1 分组 7、L2 分组 5 里"先只读、再给命令"是同一个规矩。

### 一句话记住

> 教程给的是**地图**，`git help` 是**字典**，一次性仓库是**试验台**。  
> 遇到没学过的命令：查地图有没有 → 查字典怎么用 → 试验台跑一遍 → 写进自己的踩坑记录。