我会用 Git，但它到底在做什么？从对象数据库到现代工作流

仓库与工作区不是同一个东西#

Repository（仓库） 主要指 .git 中的对象、引用和配置。Working tree（工作区或工作树） 是我在编辑器里看到、编译器会读取的那份文件集合。一个普通项目目录通常把两者放在一起：

1
pocket-git/          # 工作区根目录
2
├── README.md        # 可以直接编辑的文件
3
├── src/
4
│   └── app.txt
5
└── .git/            # 仓库元数据与对象数据库

删除工作区文件不等于立即删除历史中的 blob；删除 .git 则会让这个目录失去本地 Git 历史、refs 和 index，只剩普通文件。bare repository 没有普通工作区，服务器端仓库经常采用这种形态。

暂存区不是待上传清单#

Index（索引，也叫 staging area 或暂存区） 保存下一次 commit 准备采用的路径、文件模式和 blob ID。它不是一个只有文件名的勾选列表，也不是尚未 push 的 commit 队列，而是一份接近完整目录快照的二进制数据结构。

这解释了一个初学时很反直觉的现象：

1
printf 'version 1\n' > app.txt
2
git add app.txt
3
printf 'version 2\n' > app.txt
4
git commit -m 'record app'

这个 commit 收进去的是 version 1，因为 git add 当时把那份内容写入对象数据库并让 index 指向它。之后写入工作区的 version 2 仍未暂存。git add 更准确的理解不是”开始跟踪这个文件”，而是”把这些路径此刻的内容放入下一张快照”。

HEAD、branch 与 commit#

Commit 是不可变对象，记录根 tree、parent、身份、时间和消息。Branch 是 refs/heads/... 下会移动的引用。HEAD 表示当前检出位置，通常间接指向某个本地分支。

1
HEAD -> refs/heads/main -> commit 0063127 -> parent cd5e714

执行 git commit 时，Git 创建新 commit，再让当前分支指向它；旧 commit 没有被修改。执行 git switch topic 时，Git 改变 HEAD 所指分支，并让 index 与工作区尽量匹配目标快照。分支是名字，commit 才是历史节点。

tracked、untracked、modified 与 staged#

这些词描述的是路径与 3 份状态之间的关系：

一个文件可以同时 modified 与 staged。前面的 MM src/app.txt 就是：index 已准备一个版本，工作区又在它上面继续修改。git status 给状态摘要，git diff 展开具体内容；前者像仪表盘，后者才是示波器。

本地分支、远端跟踪分支与 upstream#

这 3 个名字也经常被混成”远端分支”：

• main 是本地分支，我可以离线提交并移动它；
• origin/main 是本地保存的 remote-tracking ref，表示上次 fetch 后我看到的远端 main；
• 服务器上的 refs/heads/main 才是远端此刻真正的分支。

Upstream 是给本地分支配置的默认比较、pull 和 push 对象。例如 git push -u origin topic 会在发布分支的同时设置 upstream。upstream 不是父 commit，也不意味着本地分支会自动与服务器同步。

最后把最常见的状态流压成 4 步：

这 4 步可以分开检查，也应该分开理解。

先选对两端#

方向很重要。git diff A B 描述的是把 A 变成 B：- 行来自 A，+ 行来自 B。交换参数，patch 的正负也会反过来。

git diff A..B 对 diff 来说与 git diff A B 基本等价，只比较两个端点；这里的 .. 不具有 git log A..B 那种”可达 commit 集合之差”语义。三点 A...B 才会先求 merge base，再把 merge base 与 B 比较。两个点和三个点长得只差一个点，含义差了一棵分叉历史（非常 Git）。

只看某些路径时，我会用 -- 明确结束 revision 参数：

1
git diff HEAD -- src/app.txt
2
git diff main...topic -- src/

这也能避免一个路径名恰好像 branch 名时产生歧义。

逐行拆一份 unified diff#

在前面的实验里，index 保存 version 2，工作区保存 version 3。运行：

1
git diff -- src/app.txt

实际输出是：

1
diff --git a/src/app.txt b/src/app.txt
2
index 1f7a7a4..7170a52 100644
3
--- a/src/app.txt
4
+++ b/src/app.txt
5
@@ -1 +1 @@
6
-version 2
7
+version 3

从上往下读。

1
diff --git a/src/app.txt b/src/app.txt

1
index 1f7a7a4..7170a52 100644

1
--- a/src/app.txt
2
+++ b/src/app.txt

1
@@ -1 +1 @@

1
@@ -<旧起始行>,<旧行数> +<新起始行>,<新行数> @@ <可选上下文>

1
@@ -10,4 +10,6 @@ function parseConfig()

1
version 2
2
version 3

1
\ No newline at end of file

新建、删除、改权限和重命名怎么看#

普通内容修改之外，extended headers 会描述文件级元数据：

1
new file mode 100644
2
deleted file mode 100644
3
old mode 100644
4
new mode 100755
5
rename from old-name.txt
6
rename to new-name.txt
7
similarity index 98%

100644 -> 100755 通常表示 executable bit 发生变化，不代表文件正文改变。重命名则需要一个重要修正：Git commit 并不存储”rename old to new”操作。Git 保存前后 tree，diff 再把一个删除和一个新增按内容相似度推断为 rename。similarity index 98% 表示 Git 认为 98% 的行没有变化；调整 rename detection 阈值可能得到不同展示，但 commit 对象没有改变。

想明确启用并设置阈值，可以：

1
git diff --find-renames=50% <A> <B>

二进制文件默认通常只显示 Binary files ... differ，不会假装把任意字节流解释成文本行。项目可以通过 .gitattributes 配置 textconv 或专用 diff driver，但那改变的是展示，不是对象内容。

适合不同阅读阶段的 diff 视图#

完整 patch 不是每次都最合适。我通常从概览逐层放大：

1
git diff --stat                 # 每个文件的增删规模
2
git diff --name-status          # 路径及 M/A/D/R 等状态
3
git diff                        # 完整未暂存 patch
4
git diff --staged               # 完整待提交 patch
5
git diff --word-diff            # 观察行内词级变化
6
git diff --check                # 检查空白错误与冲突标记

--stat 适合先判断变化范围，不能代替阅读 patch；--word-diff 对长段文字和一行内改多个 token 很有用，但它不是常规 unified patch；--check 适合提交前发现 trailing whitespace 等问题。

只想让脚本判断有无差异时：

1
git diff --quiet --exit-code

退出码 0 表示没有差异，1 表示存在差异，其他非零值通常表示真正的错误。这里不能用”命令没有打印东西，所以相同”来判断，因为 --quiet 本来就不打印。

Git 也可以离开仓库比较两个普通路径：

1
git diff --no-index old.txt new.txt

这时它很像系统 diff -u，仍使用 Git 熟悉的 patch 展示和退出码。至于 --patience、--histogram 等 diff algorithm，它们会改变 hunk 如何对齐，适合默认 Myers 算法给出难读结果时尝试；它们不会改变两端真实内容。

detached HEAD 是什么#

如果执行：

1
git switch --detach cd5e714

HEAD 会直接保存 commit ID，而不再指向 refs/heads/...。这适合检查历史或做可丢弃实验。此时提交仍然会创建合法 commit，只是没有 branch 名自动跟着它移动。切走后，那些 commit 可能变得不可达，但通常还能暂时从 reflog 找回。

普通状态下，HEAD -> branch -> commit；detached 状态则跳过 branch，变成 HEAD -> commit。少掉的正是那个会自动移动、也方便以后寻找的名字。

如果实验值得保留，在切走前给它一个名字：

1
git switch -c rescued-experiment

Fast-forward：历史没分叉，只移动指针#

先看最简单的情况。main 停在 O，topic 从 O 继续提交了 C、D，而 main 自己没有新 commit：

合并前：

合并后：

两张图中的 O、C、D 是同一批 commit。前一张图里 main 留在 O；后一张只画发生变化的 main，它已经抵达 D。topic 没有移动，仍然指向 D。

O 是 D 的祖先，所以 git merge topic 不必创建 merge commit。Git 只把 main 从 O 移到 D，commit 图一个节点都没增加；这就是 fast-forward，缩写为 ff。之后看到的 pull --ff-only 和 push 检查都在问同一个祖先关系。

merge：保留分叉，增加汇合点#

在 main 上执行：

1
git switch main
2
git merge topic

若不能 fast-forward，Git 创建一个 merge commit M：

M 有两个 parent。历史明确记录两条工作线曾经并行存在。

我会在需要保留集成边界时使用 merge，例如合入一个完整功能分支。想明确保留这个边界，可以：

1
git merge --no-ff topic

rebase：复制 commit，换一组 parent#

在 topic 上执行：

1
git switch topic
2
git rebase main

Git 找到共同祖先 O，取出 C、D 引入的补丁，再以 B 为新基底重放，得到新 commit C'、D'：

C' 与 C 的 parent 不同，所以 ID 必然不同；D' 的 parent 又变了，因此也有新 ID。rebase 不是”移动原 commit”，而是复制出一条语义相似的新历史，再移动分支引用。

我的规则很简单：

• 尚未共享的个人分支，可以 rebase、commit --amend、rebase --interactive；
• 已被其他人基于其开发的公开历史，不随意 rebase；
• 集成策略服从项目，不把”线性历史”当宗教。

交互式整理常用：

1
git rebase --interactive <base>

如果评审后只想把修补自动折叠进原 commit：

1
git commit --fixup=<commit>
2
git rebase --interactive --autosquash <base>

rebase 前后想确认 patch series 是否意外变化：

1
git range-diff <old-base>..<old-tip> <new-base>..<new-tip>

cherry-pick：复制选定的 commit#

1
git cherry-pick <commit>

它把某个 commit 引入的变化应用到当前 HEAD，再创建一个新 commit。因为 parent 通常不同，新 ID 也不同。适合把一个独立修复移到维护分支，不适合长期用来手工同步两条本应合并的分支。

冲突不是文件坏了，而是 Git 无法自动决定 3 方合并结果。先看：

1
git status
2
git diff

解决每个文件后暂存，再继续对应操作：

1
git add <resolved-path>
2
git merge --continue       # merge 场景
3
git rebase --continue      # rebase 场景
4
git cherry-pick --continue # cherry-pick 场景

不想继续时，使用相应的 --abort，不要边慌边 reset --hard。

fetch：下载对象，更新远端跟踪引用#

1
git fetch origin --prune

它与远端协商本地缺少的对象，接收 packfile，再按 refspec 更新 refs/remotes/origin/*。--prune 删除远端已经不存在的远端跟踪引用，但不会删除我的本地分支。

fetch 通常不改当前工作区、index 或本地 main，所以它是理解远端变化的好分界点：

1
git log --oneline --graph --decorate --all
2
git log --left-right --cherry-pick main...origin/main
3
git diff main...origin/main

pull：先 fetch，再选择一种集成策略#

git pull 不是与 fetch 并列的下载协议。它先 fetch，然后把上游分支集成进当前分支。真正需要决定的是第二步。

所以 pull 不是第四种历史操作。它只是把 fetch 与某一种已有的集成操作串起来。

我不喜欢让一个无参数 git pull 隐藏策略。现代、安全而可读的写法是明确选择：

1
git pull --ff-only   # 只允许快进，分叉就停下
2
git pull --rebase    # fetch 后把本地 commit 重放到上游
3
git pull --no-rebase # fetch 后 merge

对于还在建立心智模型的人，我更推荐拆成两步：

1
git fetch origin --prune
2
git log --oneline --graph --decorate --all
3
git rebase origin/main  # 或 git merge origin/main

这样每个命令只做一类事，出错时也知道哪一层出了问题。Git 版本之间默认 pull 策略可能变化，项目策略也不同；显式参数比背默认值可靠。

长期配置应选自己和团队真正采用的策略，例如：

1
git config --global pull.ff only
2
# 或
3
git config --global pull.rebase true

不要把两条都照抄。ff-only 在本地与上游分叉时停止；rebase 会重写本地尚未发布的 commit。它们表达不同政策。

push：上传缺少的对象，请远端移动 ref#

第一次发布分支：

1
git push --set-upstream origin topic

--set-upstream（缩写 -u）建立本地 topic 与上游分支的关系。以后在 push.default=simple 的常见配置下，可以直接：

1
git push

push 分成两件事：

1. 把远端缺少的可达对象发送过去；
2. 请求远端把某个 ref 从旧 ID 更新到新 ID。

普通 push 默认要求更新是 fast-forward，也就是远端旧 tip 必须是新 tip 的祖先。否则 Git 拒绝 non-fast-forward，因为直接移动 ref 可能让别人已发布的 commit 失去分支入口。

服务器检查的是可达关系，不是比较谁的时间戳更新。如果远端 tip 不是本地 tip 的祖先，直接移动 ref 就可能把一段别人仍需要的历史甩出分支可达范围。

如果我确实 rebase 了自己的远端分支，需要改写它，我使用：

1
git push --force-with-lease

它比 --force 多一个租约条件：远端 ref 必须仍是我预期的值，否则拒绝覆盖。需要最严格地表达预期值时，可以写：

1
git push \
2
  --force-with-lease=refs/heads/topic:<expected-old-oid> \
3
  origin topic

裸 --force-with-lease 通常以本地远端跟踪引用作为预期值；后台自动 fetch 可能更新这个依据，所以它不是绝对保险。--force 则直接关闭这层保护，可能丢掉远端 commit。我不会把 push -f 做成 shell alias，这种便利与拔掉烟雾报警器差不多。

常用决策表#

restore 面向路径，reset 主要移动当前 branch 并按模式决定是否同步 index 和工作区，revert 则创建新 commit。名字相似，历史兼容性完全不同。

revert 为什么适合公开历史#

1
git revert <bad-commit>

它不删除坏 commit，而是计算反向变化并创建一个新 commit。所有协作者仍共享同一条已有历史，只需继续 fast-forward。对于已经推送到公共分支的错误，这通常是最无聊也最安全的方案。

reflog：引用移动的本地黑匣子#

我做了一个故意的事故：先记住第二个 commit 0063127，再把 main 硬重置回第一个 commit：

1
git reset --hard cd5e714

git log 看不到第二个 commit 了，但 git reflog --oneline 仍显示：

1
cd5e714 HEAD@{0}: reset: moving to cd5e714...
2
0063127 HEAD@{1}: commit: feat: advance the app
3
cd5e714 HEAD@{2}: commit (initial): feat: build the first snapshot

于是我恢复：

1
git reset --hard 0063127

main 又回到了第二个 commit。reflog 记录启用了日志的 refs 与 HEAD 的近期移动；普通非裸仓库通常会记录 HEAD 和本地分支，但不是所有引用都必然有 reflog。它不会 push 到远端，也不是永久备份；条目会过期，不可达对象最终可能被垃圾回收。但在误操作之后，第一反应应该是停止继续改写，运行 git reflog，给目标 commit 新建分支：

1
git branch rescue 0063127

这条更稳妥的恢复路径最终得到下面这张历史图：

main 仍停在 cd5e714，而新建的 rescue 重新指向 0063127。这张图描述的是恢复后的 commit DAG，不是重新执行 commit 的过程：git branch rescue 0063127 只补回一个引用，没有创建 0063127。

只要对象还在，名字丢了通常比内容丢了容易修。

初始配置#

1
git config --global user.name 'Your Name'
2
git config --global user.email 'you@example.com'
3
git config --global init.defaultBranch main
4
git config --global fetch.prune true
5
git config --global merge.conflictStyle zdiff3
6
git config --global rerere.enabled true

这里前两项进入 commit 身份；fetch.prune 清理失效的远端跟踪引用；zdiff3 在冲突标记中显示 base，帮助判断双方分别改了什么；rerere 记录冲突解决结果，在相同冲突再次出现时复用。签名、凭据管理、换行符和 pull 策略依平台与团队而定，不适合复制一份”万能配置”。

检查配置来源比只看最终值更有用：

1
git config --list --show-origin

每日开始#

1
git switch main
2
git fetch origin --prune
3
git pull --ff-only
4
git switch -c feature/readable-name

如果项目要求 rebase 工作流，我会显式采用它，而不是同时配置互相冲突的习惯。

制作原子 commit#

1
git status --short --branch
2
git diff
3
git add --patch
4
git diff --staged
5
git commit

commit message 解释变化的意图和原因。标题能独立读懂，正文写约束、权衡和行为变化；不要把 update files 这种只能证明键盘工作过的句子留给历史。

同步并复核#

1
git fetch origin --prune
2
git rebase origin/main
3
git range-diff origin/main...@{upstream} origin/main...HEAD
4
git push --set-upstream origin HEAD

@{upstream} 需要当前分支已经配置 upstream；首次发布前没有它。HEAD 作为 push 源表示当前分支 tip，但目标命名和权限仍由 refspec、配置和服务端规则决定。团队若使用 merge，则换成对应流程，不要为了套模板偷偷改写历史。

阅读历史#

1
git log --oneline --graph --decorate --all
2
git log --first-parent main
3
git show <commit>
4
git diff <a>..<b>
5
git blame -L <start>,<end> -- <path>

blame 回答”这一行最后由哪个 commit 引入”，不是”该怪谁”。拿到 commit 后继续 git show 和阅读上下文，通常才有答案。

定位引入 bug 的 commit#

当我有一个可重复判定好坏的命令时，bisect 通常能在 $N$ 个 commit 中用大约 $\log_2 N$ 次判断定位边界。在线性、每个候选都可测试的理想历史中，1024 个候选 commit 约需 10 轮，而不是从头读 1024 次 diff；复杂 merge DAG 和被跳过的 commit 会增加轮数，甚至让 Git 无法唯一定位。

1
git bisect start
2
git bisect bad HEAD
3
git bisect good <known-good>
4
git bisect run ./reproduce.sh
5
git bisect reset

reproduce.sh 必须以 0 表示 good，1 到 127（除 125）表示 bad，125 表示无法测试。这个脚本值得认真写，因为错误的 oracle 会高效地把我带到错误答案，计算机在这方面一如既往地非常配合。