MIT Missing Semester 2026 第五课：版本控制与 Git#

commit 是逻辑检查点#

Git 会检测工作区变化，但不会把每次按键或每次保存自动创建为 commit。开发者应在一个逻辑工作达到可解释状态时建立提交，例如修复一个错误、加入一个完整功能或更新一组相关文档。

1
编辑文件
2
  ↓
3
git status：确认文件状态
4
  ↓
5
git diff：检查尚未暂存的修改
6
  ↓
7
git add：选择下一提交内容
8
  ↓
9
git diff --staged：复核即将提交的内容
10
  ↓
11
git commit：建立逻辑检查点

一个提交可以涉及多个文件，也可以只包含一个文件中的部分改动。关键在于其中的变化是否共同完成一个清晰意图。

快照、blob 与 tree#

Git 在概念上把每次提交看成完整快照。文件内容称为 blob，目录称为 tree，顶层 tree 代表整个项目快照。

1
<root> (tree)
2
├── foo (tree)
3
│   └── bar.txt (blob: "hello world")
4
└── baz.txt (blob: "git is wonderful")

blob 只保存字节，不保存文件名。tree 把名称和文件模式映射到 blob 或子 tree，因此文件名属于 tree 条目。内容相同的文件可以引用同一个 blob 对象。

快照模型不表示 Git 必须在磁盘上机械保存许多完整副本。对象复用、packfile 和 delta 压缩可以节省空间，但不改变提交代表完整项目状态这一概念。

commit 与 DAG#

commit 对象保存顶层 tree、父提交、作者和提交者信息、时间以及 message。

1
commit
2
├── top-level tree
3
├── parent(s)
4
├── author / committer / time
5
└── message

普通提交通常有一个父提交，初始提交没有父提交，合并提交可以有两个或更多父提交。Git 历史因此是有向无环图 DAG，而不是只能线性排列的版本列表。

1
A <- B <- C <- D
2
          \
3
           E <- F

箭头指向父提交。两条开发线合并后，可以产生具有两个父提交的新快照：

1
A <- B <- C <- D <---- M
2
          \           /
3
           E <- F <--

不可变提交与历史重写#

commit 的内容包含 tree、父提交和元数据。任一字段变化都会产生新的对象 ID。所谓修改旧提交，通常是创建新提交，再移动分支引用。

1
旧历史：A <- B <- C
2
新历史：A <- B' <- C'

这解释了 commit --amend、rebase 和 reset 为什么会改变提交 ID，也解释了共享历史重写为什么需要协调。

数据模型伪代码#

1
type blob = array<byte>
2
type tree = map<string, tree | blob>
3

4
type commit = struct {
5
    parents: array<commit>
6
    author: string
7
    message: string
8
    snapshot: tree
9
}
10

11
type object = blob | tree | commit
12
objects = map<object_id, object>
13
references = map<string, object_id>

仓库的核心可以近似理解为对象数据库加引用集合。Git 命令要么创建或读取对象，要么移动引用，要么改变工作区与暂存区以准备下一批对象。

从 HEAD 逐层找到文件内容#

假设当前快照包含：

1
project/
2
├── README.md
3
└── src/
4
    └── main.py

可以按对象关系逐层检查：

1
git cat-file -t HEAD
2
git cat-file -p HEAD
3
git cat-file -p HEAD^{tree}
4
git ls-tree -r HEAD

第一条确认 HEAD 最终解析为 commit；第二条显示该 commit 的顶层 tree、父提交和元数据；第三条打印顶层 tree，因此根目录下的 src 只表现为另一个 tree；第四条递归展开整个快照，显示 src/main.py 对应的 blob。

1
HEAD
2
  ↓
3
commit C
4
  ↓ tree 字段
5
root tree T
6
├── README.md → blob A
7
└── src       → tree S
8
                └── main.py → blob B

HEAD^{tree} 可以读作“把 HEAD 对应的对象解析为 tree”。HEAD~^{tree} 从 HEAD 的父提交取得顶层 tree。git hash-object README.md 默认只计算 blob ID，增加 -w 才写入对象数据库。

日常命令常称为 porcelain，底层命令常称为 plumbing。理解底层有助于建立模型，但普通工作不应手工修改 .git/objects 或 .git/refs。

分支是可移动引用#

1
refs/heads/main -> commit C

创建新提交 D 后，Git 把 main 移到 D：

1
A <- B <- C <- D
2
               ^
3
               main

创建分支只需增加另一个引用，不需要复制整个项目：

1
A <- B <- C
2
          ^
3
          main
4
          experiment

这就是 Git 分支轻量的原因。

tag 是相对稳定的名称#

轻量 tag 近似固定引用，附注 tag 则有独立 tag 对象，可以包含标记者、说明和签名。tag 常用来标识发布版本，分支则用于持续开发。

1
git tag v1.0
2
git tag -a v1.0 -m "Version 1.0"

1
轻量 tag：v1.0 → commit C
2

3
附注 tag：v1.0 → tag object T → commit C
4
                    ├── tagger
5
                    ├── time
6
                    ├── message
7
                    └── optional signature

正式发布通常更适合附注 tag。后续提交会推动当前分支前进，但不会自动移动 v1.0。

删除引用与对象可达性#

1
git branch -d experiment

这条命令主要删除分支引用，不会立即逐个删除它曾经指向的 commit、tree 和 blob。Git 从分支、tag 等引用出发，沿父提交关系判断对象是否可达：

1
main → D → C → B → A    A、B、C、D 可达
2

3
E                        没有普通引用可达

不可达对象可能暂时仍存在，并可能通过 reflog 找回；经过过期和垃圾回收后才可能被清理。

HEAD 记录当前位置#

通常：

1
HEAD -> refs/heads/main -> commit D

新提交完成后，main 前进，HEAD 继续通过当前分支指向最新提交。

直接检出某个提交 ID 会进入 detached HEAD：

1
HEAD -> commit B

可以用聚焦的新命令或传统命令进入这一状态：

1
git switch --detach <revision>
2
git checkout <revision>

此时可以检查和实验，也能创建提交；若希望保留新工作，应及时创建分支：

1
git switch -c rescue-branch

正常状态的完整寻址链是：

1
HEAD → refs/heads/main → commit C → root tree → child tree/blob

HEAD 表示当前位置，分支表示开发线当前位于哪个 commit，commit 保存快照入口和历史关系，tree 保存名称与目录结构，blob 保存文件内容。切换分支主要改变 HEAD 所关联的引用；创建提交时真正向前移动的是当前分支引用。

git add 保存执行时的内容#

1
git add report.md

这条命令把 report.md 当前内容放入 index。随后继续编辑产生的新修改只在工作区，必须再次执行 git add 才会进入下一提交。

1
第一次编辑 -> git add -> 暂存版本 A
2
继续编辑              -> 工作区版本 B
3
git commit            -> 只提交版本 A

同一个文件的三个版本可以表示为：

最后一种状态表示 commit 已经保存 Version 2，而 Version 3 仍作为未提交修改留在工作区。

暂存区使一个工作目录中的 bug 修复、未完成功能和调试输出可以被拆成多个清晰快照。git add -p 还能选择同一文件中的部分 hunk。

三种 diff#

1
git diff                 # 工作区 vs 暂存区
2
git diff --staged        # 暂存区 vs HEAD
3
git diff HEAD            # 工作区与暂存内容综合对比 HEAD

提交前通常应依次检查：

1
git status
2
git diff
3
git diff --staged

git commit 默认只把暂存区写成新提交，未暂存修改保留在工作区。

当同一个文件处于 HEAD=A、index=B、working tree=C 时，git status 可能同时把它列为 Changes to be committed 和 Changes not staged for commit。前者表示 A→B 已暂存，后者表示 B→C 尚未暂存。

基础配置#

1
git config --global user.name "Your Name"
2
git config --global user.email "you@example.com"
3
git config --global init.defaultBranch main

姓名和邮箱进入提交元数据，不等于 GitHub 登录凭据。公开仓库应考虑邮箱隐私设置。

--global 为当前操作系统用户设置默认值；仓库内的 local 配置通常会覆盖它：

1
git config --global user.name "Default Name"
2
git config user.email "project-specific@example.com"
3
git config --list --show-origin

作者元数据和远端认证是两个独立问题。远端权限由 SSH 密钥、令牌、账号权限与服务器策略决定。

最小工作流#

1
mkdir demo
2
cd demo
3
git init
4

5
printf '# Demo\n' > README.md
6
git status
7
git add README.md
8
git diff --staged
9
git commit -m "docs: add project overview"
10
git log --oneline --decorate

底层变化如下：

1. git init 创建 .git 元数据目录；
2. 工作区出现未跟踪文件；
3. git add 把内容加入 index，并创建或复用 blob；
4. git commit 从 index 构造 tree 和 commit；
5. 当前分支引用移动到新 commit；
6. HEAD 继续通过当前分支指向最新提交。

刚执行 git init、尚无提交时，可以近似表示为：

1
HEAD → refs/heads/main
2
main 尚未指向任何 commit

第一次 commit 创建 root commit 后才形成：

1
HEAD → main → commit A → tree → blob

.git/ 保存对象数据库、refs、HEAD、index、配置和引用日志等仓库数据。项目文件构成工作区；.git/ 损坏或丢失会使该目录失去对应的本地历史与元数据。

帮助、状态与历史#

1
git help commit
2
git status --short
3
git log --oneline --decorate
4
git log --all --graph --decorate --oneline
5
git show HEAD
6
git show HEAD:README.md
7
git log -- README.md

git status 是出现混乱时的首要诊断工具。git log 显示从指定起点可达的提交，不等于对象数据库中的所有对象；--all 使用全部引用作为起点。

短状态格式的两列分别反映 index 和工作区，例如：

1
?? notes.txt    未跟踪
2
A  README.md    已加入 index
3
 M main.py      工作区修改尚未暂存
4
MM model.py     已暂存后又继续修改

git show HEAD:README.md 读取 HEAD 快照中的文件，而不是工作区当前版本。git log -- README.md 中的 -- 用于分隔 Git 参数与路径，只查看与该路径相关的提交。

创建和切换分支#

1
git branch
2
git branch feature/login
3
git switch feature/login
4
git switch -c feature/payment

旧式 git checkout -b feature/login 仍然常见。switch 更聚焦分支，restore 更聚焦文件恢复，可以减少 checkout 一条命令承担多种语义的混淆。

fast-forward 与 merge commit#

若当前分支没有额外提交，merge 只需把引用向前移动：

1
A <- B <- C
2
^         ^
3
main      feature
4

5
git switch main
6
git merge feature
7

8
A <- B <- C
9
          ^
10
          main, feature

这叫 fast-forward，不产生新的 merge commit。

若两边都继续提交，Git 会寻找共同祖先并执行三方合并：

1
      D <- E  feature
2
     /
3
A <- B <- C  main

成功后可以产生拥有两个父提交的 merge commit。

三方合并比较共同祖先 B、当前分支 C 和待合并分支 E。假设 B 中为：

1
name = "Alice"
2
age = 18

C 只把 age 改为 19，E 只把 name 改为 Bob。Git 比较 B→C 和 B→E 后，可以判断两项修改互不冲突并得到：

1
name = "Bob"
2
age = 19

共同祖先为两条开发线提供修改基线，因此三方合并比只比较 C 与 E 更有信息。

解决合并冲突#

若两个分支从共同祖先出发，对同一区域作出无法自动协调的修改，Git 会写入冲突标记：

1
<<<<<<< HEAD
2
1 cup salt
3
=======
4
2 cups sugar
5
>>>>>>> sweet

HEAD 一侧是当前分支内容，另一侧是待合并分支内容。应编辑出最终正确版本，删除全部标记，再完成合并：

1
git status
2
git diff
3
git add recipe.txt
4
git merge --continue

也可以调用已配置的图形或终端合并工具：

1
git mergetool

放弃尚未完成的 merge：

1
git merge --abort

冲突期间三层模型仍然成立。HEAD 表示当前分支一侧，MERGE_HEAD 记录待合并提交；index 可以为冲突路径保留共同祖先、当前一侧和待合并一侧的多个阶段。开发者编辑工作区中的最终内容，再用 git add 更新 index 并标记该路径已经解决：

1
共同祖先 / HEAD / MERGE_HEAD
2
             ↓ Git 尝试合并
3
       index 中出现冲突阶段
4
             ↓ 编辑工作区
5
          git add path
6
             ↓
7
       index 保存最终版本
8
             ↓
9
     git commit 或 merge --continue

最终内容可以采用任一版本、组合两者，或者根据程序语义重新编写；解决冲突不等同于机械选择冲突标记的某一侧。

rebase 的模型#

1
      D <- E  feature
2
     /
3
A <- B <- C  main

在 feature 上执行：

1
git rebase main

Git 把 feature 相对共同祖先的修改重放到 C 后面：

1
A <- B <- C <- D' <- E'
2
          main       feature

D' 和 E' 是新提交。rebase 可以得到线性历史，却会改变提交 ID。不要在未经协调时 rebase 已被他人使用的共享提交。

逐提交重放可以分解为：提取 B→D 的修改并在 C 上应用，创建 D'；再提取 D→E 的修改并在 D' 上应用，创建 E'。父提交字段从 B、D 变成 C、D’，因此新 commit 的内容和 ID 必然变化。

merge 保存分叉和合并拓扑，rebase 重写开发线的基底。选择应服从团队工作流。

1
git status
2
git add <resolved-path>
3
git rebase --continue
4

5
# 放弃整次 rebase，回到开始前
6
git rebase --abort

clone#

1
git clone <url>

clone 通常创建本地仓库、下载对象和引用、添加 origin、建立本地分支与 upstream，并检出工作区。origin 只是默认名称。

clone 与下载 ZIP 不同。ZIP 通常只包含某个时刻的文件；clone 还会建立 .git/、取得提交历史与引用、配置 remote 并检出默认分支。浅克隆是有意只取得有限历史的例外。

fetch#

1
git fetch origin

fetch 获取对象和远端引用，并更新 origin/main 等远程跟踪引用。它通常不自动合并到本地 main，也不直接覆盖当前工作区。

1
refs/heads/main          本地分支
2
refs/remotes/origin/main 本地记录的远端 main 状态

远程协作需要同时区分三层引用：

1
服务器上的 main
2
        │ git fetch
3
        ▼
4
本地的 origin/main
5
        │ git merge / git rebase
6
        ▼
7
本地的 main

origin/main 是最近一次与 origin 通信后，本地记录的远端 main 位置，不是服务器状态的实时镜像。fetch 后可以使用 git log main..origin/main 查看远程跟踪分支有而本地 main 没有的提交，或用 git diff main origin/main 比较两端快照。

pull#

课程把 pull 概括为 fetch 后 merge。实际行为还会受到 upstream、pull.rebase、pull.ff 和命令选项影响。

需要明确控制时可以拆开：

1
git fetch origin
2
git merge origin/main

采用 rebase 工作流时可显式使用：

1
git pull --rebase

push 与 upstream#

1
git push origin main
2
git push -u origin main
3
git push origin local-name:remote-name
4
git branch --set-upstream-to=origin/main main
5
git branch -vv

push 发送远端缺少的对象，并请求更新远端引用。服务器可能因非 fast-forward、分支保护、权限或检查失败而拒绝。

push 不会直接上传尚未形成 commit 的工作区或 index 内容：

1
工作区修改 → git add → index → git commit → 本地对象与引用 → git push → 远端对象与引用

因此修改文件后立即 push 不能代替 add 和 commit。

local-name:remote-name 是 push refspec 的直观形式。例如 git push origin feature:dev 请求用本地 feature 更新远端 dev；git push origin main 在常见情形下相当于 main:main。若远端分支含有本地没有的提交，直接更新会让其历史无法通过父提交链 fast-forward 到新位置，服务器通常以 non-fast-forward 拒绝。此时应先 fetch，再用 merge 或 rebase 整合远端变化，而不是立即强制覆盖。

upstream 是本地分支默认比较、拉取或推送的远程跟踪分支。它不是父提交，也不等同于社区常命名为 upstream 的 remote。

1
本地 main ──upstream──> origin/main

这项本地配置使 git status、无参数 git pull 和 git push 知道默认与谁比较或通信，也使 Git 能报告 ahead、behind 或 diverged。git push -u origin feature 是推送并设置 upstream；git branch --set-upstream-to=origin/main main 只设置关系，不发生网络传输。git branch -vv 可检查每个本地分支的当前提交、upstream 与领先/落后状态。

配置来源#

1
git config --list --show-origin
2
git config --global core.editor "vim"
3
git config --local user.email "project@example.com"

Git 配置存在 system、global、local 等层级，后者通常覆盖前者。--show-origin 可以查明某个值来自哪个文件。

浅克隆#

1
git clone --depth=1 <url>

浅克隆只获取有限历史，可减少时间和空间，但 log、blame、bisect、合并基础和历史分析可能受限。

需要更多或完整历史时可以执行：

1
git fetch --deepen=100
2
git fetch --unshallow

交互暂存#

1
git add -p

按 hunk 选择进入 index 的修改，适合把混杂的工作区拆成多个单一意图提交。

常见提示 Stage this hunk [y,n,q,a,d,...]? 中，y 表示暂存当前 hunk，n 表示跳过当前 hunk，q 表示退出并停止处理后续 hunk，a 表示暂存当前及后续 hunk，d 表示当前及后续 hunk 都不暂存。它是在逐块决定哪些修改进入下一提交，不是立即 commit 或上传。

交互 rebase#

1
git rebase -i HEAD~5

可以重排、合并、修改或删除本地提交。它会重写相关提交，适合尚未共享的开发线。

fixup 和 squash 总是合入它们上方最近的保留提交；edit 是先应用再暂停。完成暂停处的修改后执行 git rebase --continue。由于 Git 是按新顺序重新创建提交，重排也不是简单移动原对象。

blame#

1
git blame -L 20,40 path/to/file

blame 显示当前每行最后归因到哪个提交，不自动解释原始作者、复制来源和修改动机。应结合 git show、git log -L 与 message。

stash#

1
git stash push -m "wip: parser experiment"
2
git stash list
3
git stash show -p stash@{0}
4
git stash pop
5
git stash apply stash@{0}

stash 暂存工作区与 index 变化并清理现场。apply 恢复指定 stash 但保留该条目，pop 恢复后尝试从列表移除。默认不一定包含 untracked 或 ignored 文件；需要时可用 -u 纳入 untracked，或用 -a 进一步纳入 ignored。重要成果不应长期只保存在 stash。

bisect#

1
git bisect start
2
git bisect bad
3
git bisect good <known-good-commit>
4
# 对 Git 选出的提交进行测试，然后标记 good 或 bad
5
git bisect reset

bisect 在提交历史上二分定位首次回归。若测试可以脚本化，可使用 git bisect run <test-command>。

worktree#

1
git worktree add ../project-hotfix hotfix
2
git worktree list
3
git worktree remove ../project-hotfix

worktree 允许同一仓库同时检出多个分支，适合在保留实验现场的同时处理紧急修复。

worktree 是工作目录，不是新的历史线。真正前进的是各目录中检出的 branch；整合时也应 merge、rebase 或 cherry-pick 分支，而不是手工复制目录：

1
共享对象数据库
2
├── project/         → feature 分支
3
└── project-hotfix/  → hotfix 分支

在 hotfix worktree 中提交后，可回到 feature 或 main 所在 worktree 执行 git merge hotfix。worktree 解决同时在哪些目录工作，分支操作解决这些提交历史如何整合。

.gitignore#

1
.DS_Store
2
.venv/
3
__pycache__/
4
*.log
5
build/

ignore 主要影响未跟踪文件，不会让已跟踪文件停止跟踪。要停止跟踪但保留本地文件，需要在确认影响后执行：

1
git rm --cached path

项目共同规则应写入仓库内 .gitignore；只与个人系统或编辑器有关的模式可以放入 global excludes。

因此 git add . 可能暂存已跟踪的 main.py 修改，同时跳过匹配 *.log 的未跟踪 debug.log；若 debug.log 早已 tracked，它仍会被暂存。

AI 项目中的跟踪边界#

Git 适合管理代码、文档、小型配置、测试和可复现实验脚本：

1
README.md
2
requirements.txt
3
src/
4
configs/
5
tests/
6
scripts/

数据集、模型 checkpoint、训练输出、缓存、虚拟环境和包含凭据的环境文件通常不应直接进入普通 Git 历史：

1
data/
2
checkpoints/
3
outputs/
4
wandb/
5
.venv/
6
.env
7
__pycache__/

这些内容可能造成仓库快速膨胀、二进制历史难以比较或凭据泄露。项目应为数据与制品选择合适的独立存储，并通过 .gitignore 排除本地产物。.gitignore 不能代替密钥管理；公开示例配置只应保留变量名和说明，不包含真实凭据。

环境本身和环境描述也应区分：.venv/ 是可重建的本地环境，通常忽略；requirements.txt、锁文件或其他环境声明应提交。真实 .env 保存秘密并应忽略，而可提交的 .env.example 只列出变量名和无敏感值的说明。Git 由此保存如何产生结果的代码、配置与依赖描述，大型数据、checkpoint 和实验输出则交给适合的数据或制品存储系统。

把命令映射回数据模型#

阅读 Pro Git 或使用 Learn Git Branching 时，可以为每条命令标注模型变化：

调查课程网站仓库历史#

1
git clone <course-repository-url>
2
cd missing-semester
3

4
git log --all --graph --decorate --oneline
5
git log -1 -- README.md
6
git blame -L '/collections:/,+1' _config.yml
7
git show <blame-output中的提交ID>
8
git log -S'collections:' -p -- _config.yml

仓库会继续变化，因此最后修改者、提交 ID 和 message 应以执行时结果为准。

从多次提交的历史中移除文件#

只应在可丢弃的练习仓库中实验：

1
git filter-repo --invert-paths --path path/to/large-file.bin
2
git log --all -- path/to/large-file.bin
3
git rev-list --objects --all | grep 'large-file.bin'

真实秘密泄露时，第一步是撤销或轮换凭据。之后才是隔离协作、使用最新 git-filter-repo 清理历史、验证全部引用、协调强制更新并处理缓存、fork 与其他克隆。

历史清理会改变后继提交 ID，可能破坏签名和 pull request，也不能让已经泄露的 token 恢复安全。

暂存正在进行的修改#

1
printf '\nwork in progress\n' >> README.md
2
git stash push -m "wip: README experiment"
3
git stash list
4
git log --all --oneline --decorate
5
git stash show -p stash@{0}
6
git stash pop

stash 适合短暂切换任务或恢复干净工作区。重要成果应形成分支和 commit。

创建 git graph alias#

1
git config --global alias.graph \
2
  "log --all --graph --decorate --oneline"
3
git graph

对应配置：

1
[alias]
2
    graph = log --all --graph --decorate --oneline

以 ! 开头的 alias 会交给 Shell，能力更强，也有更高的注入与可移植性风险。

配置全局 ignore#

1
git config --global core.excludesFile ~/.gitignore_global

在该文件中加入本机或编辑器临时项：

1
.DS_Store
2
Thumbs.db
3
*~
4
*.swp

1
git config --global --get core.excludesFile
2
git check-ignore -v path/to/test-file

团队共同规则应写入项目 .gitignore 并提交。

提交有价值的 pull request#

标准流程是 fork 仓库、clone 自己的 fork、建立主题分支、完成真实改进、检查 diff 与测试、push 分支并创建 pull request。课程明确要求不要为了完成练习发送无价值或重复 PR；找不到真实改进时可以跳过。

制造并解决合并冲突#

1
git init -b main conflict-lab
2
cd conflict-lab
3

4
printf '1 cup sugar\n2 cups flour\n' > recipe.txt
5
git add recipe.txt
6
git commit -m "recipe: add base recipe"
7

8
git branch salty
9
git branch sweet
10

11
git switch salty
12
printf '1 cup salt\n2 cups flour\n' > recipe.txt
13
git add recipe.txt
14
git commit -m "recipe: make salty variant"
15

16
git switch sweet
17
printf '2 cups sugar\n2 cups flour\n' > recipe.txt
18
git add recipe.txt
19
git commit -m "recipe: make sweeter variant"
20

21
git switch main
22
git merge salty
23
git merge sweet

第二次 merge 会制造冲突。编辑最终内容并删除冲突标记后：

1
git add recipe.txt
2
git merge --continue
3
git log --graph --decorate --oneline --all

本例通过 git init -b main 显式固定默认分支名，避免不同 Git 配置使用 main 或 master 造成步骤差异。