21 — 额外命令：同时开两个窗口、自动检查哨

摘要：本章介绍 Git 五个进阶工具，解决日常开发中的效率痛点。git worktree 让你同时在不同分支上工作，无需来回切换；Git hooks 作为"自动检查哨"，在提交、推送等关键节点自动执行检查；git blame 逐行追溯代码作者；git shortlog 统计团队贡献；git clean 安全清理未跟踪文件。通过生活化类比、动手示例和对照表，帮助读者快速掌握这些"加分工具"，提升 Git 使用效率与规范性。

写在前面：这一章要解决什么

你用 Git 干活到一定阶段，总会碰到两类烦心事：

你正在 feature 分支写新功能，老师让你赶紧修个线上 bug。你要么 stash 藏起来切走，要么克隆一份仓库------都不够顺手。
每次提交才发现忘了格式化，或者提交消息写得不规范，被队友吐槽。能不能让 Git 帮你 自动检查？

这章给你两个「加分工具」，再补几个查问题、清垃圾的小命令：

git worktree：同时开两个窗口看两个频道，不用来回切
Git 钩子（hooks）：门口的保安，满足条件才让进
git blame：逐行查谁改的
git shortlog：看谁贡献了多少
git clean：清掉没人管的垃圾文件

学完后，你应该能：

用 git worktree 同时在两个分支上干活
启用一个 pre-commit 钩子自动检查代码
用 blame 查某一行是谁写的
用 shortlog 快速看团队贡献
用 clean 安全地清理工作区垃圾

读者设定： 大一同学，会基本工作流、分支、远程，想再提效率。

1. 定位：为什么要学「额外命令」

1.1 一句话先记住

worktree = 同时开两个窗口看两个频道；hooks = 门口的保安，满足条件才让进。

工具	解决什么麻烦
`git worktree`	想同时看两个分支，不想来回切
Git hooks	想自动检查，不想每次手动
`git blame`	想知道某行代码是谁写的
`git shortlog`	想快速看每人贡献了几次
`git clean`	工作区一堆垃圾文件想清掉

1.2 没有它们会怎样

场景	没工具	有工具
同时改两个分支	`stash` 来回切，容易乱	`worktree` 开两个窗口并行
提交不规范代码	事后被队友吐槽	`pre-commit` 钩子自动挡住
提交消息格式乱	审查时看不懂	`commit-msg` 钩子自动检查
想问「这行谁写的」	翻历史翻到眼花	`blame` 一行查到人
想看团队贡献	数提交数数到头秃	`shortlog` 一条命令汇总
工作区一堆临时文件	手动一个个删	`clean` 一步清掉

1.3 生活里的类比

你已经会的	命令对应
电视开两个频道同时看	`worktree`
小区门口保安查证件	`hooks`
问「这句话谁说的」	`blame`
看光荣榜排名	`shortlog`
大扫除扔掉没人要的东西	`clean`

1.4 本章内容目标

目标	你能做到
并行工作	用 `worktree` 同时在两个分支干活
自动检查	启用 `pre-commit` 或 `commit-msg` 钩子
溯源	`blame` 查每一行是谁改的
纵览	`shortlog` 看贡献汇总
清理	`clean` 安全删除未跟踪文件

2. 本质：各管什么

2.1 `git worktree`：同一仓库的第二个窗口

一个仓库可以拥有 多个工作目录，每个目录检出不同分支。
这些工作目录共享同一个 .git 数据库（省空间），但文件各自独立。
就像电视机开了两个频道：一个看新闻、一个看综艺，互不打扰。

2.2 Git hooks：门口的保安

钩子是 在特定时机自动运行的脚本。
放在 .git/hooks/ 目录下，Git 在固定节点（提交前、推送前等）会去调用。
脚本退出码为 0 = 放行；非 0 = 拦住，操作不会发生。
就像门口的保安：证件合格才让你进，不合格就拦住。

2.3 `git blame`：逐行查作者

对某个文件逐行显示 谁在哪个提交改了这一行。
适合溯源：这行有 bug，谁写的？什么时候引入的？

2.4 `git shortlog`：贡献汇总

按作者统计提交数，输出一份 谁提交了几次 的摘要。
适合快速了解项目活跃度。

2.5 `git clean`：清垃圾

删除 未跟踪 的文件和目录。
跟 git reset 不同：reset 动的是已跟踪的，clean 动的是没人管的。
默认只删文件，加 -d 才删目录，加 -f 才真删。

2.6 几条硬规矩

规矩	白话
同一个分支不能同时检出在两个 worktree	会冲突，就像一个人不能同时站两个位置
钩子脚本必须可执行	否则 Git 当它不存在
钩子不会随仓库推送	别人克隆你的仓库，钩子不会跟过去
`blame` 只看最后一次改动	某行可能被多人改过，blame 只显示最后一个
`clean` 删了就没了	没进过 Git 的文件，删了无法恢复
先 `-n` 再 `-f`	`clean` 一定要先试运行

2.7 新手最常踩的坑

坑	表现	办法
worktree 里又检出同分支	报错，不允许	一个分支只在一个 worktree 里
钩子脚本不可执行	钩子不触发	`chmod +x` 加执行权限
钩子带 `.sample` 后缀	不生效	去掉 `.sample` 才激活
`clean` 忘了加 `-n` 试运行	文件直接删了，找不回来	养成习惯：先 `-n` 看，再 `-f` 删
worktree 用完不删	目录越积越多	`git worktree remove` 清理
推送后别人没有钩子	钩子是本地的	用工具（如 `husky`）或文档告诉队友

3. 建议学习顺序

text 复制代码

先会 worktree（最直观的效率提升）
  → 再会 hooks（自动化提效）
  → 然后会 blame（查问题）
  → 再会 shortlog（看全局）
  → 最后会 clean（清垃圾）

4. 动手准备

bash 复制代码

mkdir lab-extra
cd lab-extra
git init -b main
git config user.name "Ada Example"
git config user.email "ada@example.com"

先提交一点内容当基础：

bash 复制代码

printf '第一行代码\n' > app.py
printf '第二行代码\n' >> app.py
printf '第三行代码\n' >> app.py
git add app.py
git commit -m "feat: 初始版本"

验证环境：

bash 复制代码

git --version

text 复制代码

git version 2.43.0

5. 跟着做：每个工具各来一次

5.1 `git worktree`：同时开两个窗口

5.1.1 再建一个分支当素材

bash 复制代码

git switch -c feature/new-ui
printf '新界面代码\n' >> app.py
git add app.py
git commit -m "feat: 新界面"
git switch main

5.1.2 创建 worktree

现在你在 main 分支，想同时在 feature/new-ui 上干活，不用切来切去：

bash 复制代码

git worktree add ../lab-extra-hotfix feature/new-ui

text 复制代码

Preparing worktree (checking out 'feature/new-ui')
HEAD is now at 7c77c98 feat: 新界面

白话翻译： 在 ../lab-extra-hotfix 目录新建了一个工作区，检出了 feature/new-ui 分支。现在你有两个窗口，一个是 lab-extra（在 main），一个是 lab-extra-hotfix（在 feature/new-ui）。

5.1.3 看看当前所有 worktree

bash 复制代码

git worktree list

text 复制代码

/home/user/lab-extra           7c77c98 [main]
/home/user/lab-extra-hotfix    7c77c98 [feature/new-ui]

白话翻译： 两个工作目录，各在各的分支上，互不干扰。

5.1.4 在新 worktree 里干活

bash 复制代码

cd ../lab-extra-hotfix
printf '热修复代码\n' >> app.py
git add app.py
git commit -m "fix: 热修复"

回到主目录继续在 main 干活：

bash 复制代码

cd ../lab-extra
printf '主线继续开发\n' >> app.py
git add app.py
git commit -m "feat: 主线新功能"

关键点： 两个目录里的改动互不影响，不需要 stash，不需要切分支。

5.1.5 用完删掉 worktree

bash 复制代码

cd ../lab-extra
git worktree remove ../lab-extra-hotfix
git worktree list

text 复制代码

/home/user/lab-extra  399c46d [main]

白话翻译： 工作目录删掉了，但那个分支上的提交还在（提交在 .git 数据库里，删的只是工作目录）。

5.2 Git hooks：门口的保安

5.2.1 钩子住在哪

bash 复制代码

ls .git/hooks/

text 复制代码

applypatch-msg.sample    pre-merge-commit.sample
commit-msg.sample        pre-push.sample
fsmonitor-watchman.sample pre-rebase.sample
post-update.sample       pre-receive.sample
pre-applypatch.sample    prepare-commit-msg.sample
pre-commit.sample        update.sample

白话翻译： 这些带 .sample 后缀的都是示例，Git 不执行它们。去掉 .sample 就激活了。

5.2.2 启用 `pre-commit` 钩子：提交前自动检查

复制一份示例，去掉 .sample：

bash 复制代码

cp .git/hooks/pre-commit.sample .git/hooks/pre-commit

看看里面写了什么：

bash 复制代码

head -5 .git/hooks/pre-commit

text 复制代码

#!/bin/sh
#
# An example hook script to verify what is about to be committed.
# Called by "git commit" with no arguments.

白话翻译： 默认的 pre-commit 示例会检查空白错误。它是个 shell 脚本，提交前 Git 自动跑一遍，退出码 0 才放行。

让它可执行（在 Linux / macOS 上需要；Windows 上 Git Bash 通常自动处理，但保险起见加上）：

bash 复制代码

chmod +x .git/hooks/pre-commit

试试看------故意提交一个有行尾空白的文件：

bash 复制代码

printf '有空白的行   \n' > bad.py
git add bad.py
git commit -m "test: 故意有空白"

text 复制代码

bad.py:1: trailing whitespace.
+有空白的行   
test: 故意有空白
 1 file changed, 1 insertion(+)

白话翻译： 钩子检测到了行尾空白，打印了警告，但默认示例脚本没拦住（退出码仍是 0）。如果你想让它拦住，就改脚本的逻辑------让它在检测到问题时返回非 0。

写一个真正会拦住的 pre-commit：

bash 复制代码

cat > .git/hooks/pre-commit << 'SCRIPT'
#!/bin/sh
# 检查：如果有 TODO 就不让提交
if git diff --cached --name-only | xargs grep -l "TODO" 2>/dev/null; then
  echo "错误：提交中有 TODO，请先处理完再提交"
  exit 1
fi
exit 0
SCRIPT

让脚本可执行，然后试一下：

bash 复制代码

chmod +x .git/hooks/pre-commit
printf 'TODO: 这里还没写完\n' > todo.py
git add todo.py
git commit -m "feat: 带TODO的提交"

text 复制代码

todo.py
错误：提交中有 TODO，请先处理完再提交

提交被拦住了！

bash 复制代码

git status

text 复制代码

On branch main
Changes to be committed:
  new file:   todo.py

白话翻译： 文件还在暂存区，但提交没成功。处理完 TODO 再提交就行。

5.2.3 启用 `commit-msg` 钩子：检查提交消息

bash 复制代码

cat > .git/hooks/commit-msg << 'SCRIPT'
#!/bin/sh
# 检查：提交消息必须以 feat/fix/docs/chore/style/refactor/test 开头
MSG=$(cat "$1")
if ! echo "$MSG" | grep -qE "^(feat|fix|docs|chore|style|refactor|test)(\(.+\))?: .+"; then
  echo "错误：提交消息格式不对，请用 feat/fix/docs/chore/style/refactor/test: 描述"
  exit 1
fi
exit 0
SCRIPT
chmod +x .git/hooks/commit-msg

试一下错误消息：

bash 复制代码

git commit -m "随便写的消息"

text 复制代码

错误：提交消息格式不对，请用 feat/fix/docs/chore/style/refactor/test: 描述

再试正确格式：

bash 复制代码

git commit -m "chore: 清理TODO"

text 复制代码

[main 8f2a31c] chore: 清理TODO
 1 file changed, 1 insertion(+)

白话翻译： 钩子帮你看门了------消息格式不对就拦住，对了才放行。

5.2.4 `pre-push` 钩子：推送前检查

bash 复制代码

cat > .git/hooks/pre-push << 'SCRIPT'
#!/bin/sh
# 检查：不允许直接推到 main
while read local_ref local_oid remote_ref remote_oid; do
  if [ "$remote_ref" = "refs/heads/main" ]; then
    echo "错误：不允许直接推送到 main，请用合并请求"
    exit 1
  fi
done
exit 0
SCRIPT
chmod +x .git/hooks/pre-push

白话翻译： 现在 git push origin main 会被拦住，防止你一激动把不稳定的代码直接推到主线。

5.2.5 `prepare-commit-msg` 钩子：自动生成提交消息模板

bash 复制代码

cat > .git/hooks/prepare-commit-msg << 'SCRIPT'
#!/bin/sh
# 在提交消息文件开头加一个模板提示
if [ "$2" = "" ]; then
  # 只在普通 commit 时加（merge、squash 等不加）
  echo "# 格式: feat/fix/docs/chore: 描述" > "$1.tmp"
  echo "" >> "$1.tmp"
  cat "$1" >> "$1.tmp"
  mv "$1.tmp" "$1"
fi
SCRIPT
chmod +x .git/hooks/prepare-commit-msg

白话翻译： 下次 git commit 打开编辑器时，消息框里会预填一行格式提示。

5.2.6 钩子速查

钩子	什么时候跑	典型用途
`pre-commit`	`git commit` 之前	代码格式检查、lint
`prepare-commit-msg`	编辑提交消息之前	自动填充模板
`commit-msg`	提交消息写好之后	验证消息格式
`pre-push`	`git push` 之前	运行测试、保护 main

5.3 `git blame`：谁改了这一行

给 app.py 多加点历史：

bash 复制代码

printf 'Ada写的功能\n' >> app.py
git add app.py
git commit -m "feat: Ada加的功能"

git config user.name "Bob Example"
git config user.email "bob@example.com"
printf 'Bob写的修复\n' >> app.py
git add app.py
git commit -m "fix: Bob的修复"

# 改回 Ada
git config user.name "Ada Example"
git config user.email "ada@example.com"

查看每行是谁写的：

bash 复制代码

git blame app.py

text 复制代码

a1819a31 (Ada Example   2026-07-25 10:00:01 +0800 1) 第一行代码
a1819a31 (Ada Example   2026-07-25 10:00:01 +0800 2) 第二行代码
a1819a31 (Ada Example   2026-07-25 10:00:01 +0800 3) 第三行代码
c4b21f88 (Ada Example   2026-07-25 10:05:01 +0800 4) Ada写的功能
e7d32aab (Bob Example   2026-07-25 10:10:01 +0800 5) Bob写的修复

白话翻译： 每一行前面显示了提交哈希、作者、时间。第 5 行是 Bob 在那个提交里写的。

只看某几行：

bash 复制代码

git blame -L 4,5 app.py

text 复制代码

c4b21f88 (Ada Example   2026-07-25 10:05:01 +0800 4) Ada写的功能
e7d32aab (Bob Example   2026-07-25 10:10:01 +0800 5) Bob写的修复

白话翻译： -L 4,5 只看第 4 到第 5 行，省得刷屏。

5.4 `git shortlog`：贡献汇总

bash 复制代码

git shortlog -sn

text 复制代码

     4  Ada Example
     1  Bob Example

白话翻译： -s 只显示数字，-n 按数字从大到小排。Ada 提交了 4 次，Bob 提交了 1 次。

不加参数也能看，只是更详细：

bash 复制代码

git shortlog

text 复制代码

Ada Example (4):
      feat: 初始版本
      feat: Ada加的功能
      feat: 主线新功能
      chore: 清理TODO

Bob Example (1):
      fix: Bob的修复

白话翻译： 按人分组，列出每人的提交消息。项目期末要写贡献说明时，这命令太有用了。

5.5 `git clean`：清掉没人管的东西

造点垃圾文件：

bash 复制代码

printf '临时\n' > temp.log
printf '缓存\n' > cache.tmp
mkdir -p build
printf '产物\n' > build/output.bin

bash 复制代码

git status

text 复制代码

On branch main
Untracked files:
  build/
  cache.tmp
  temp.log

5.5.1 先试运行（不真删）

bash 复制代码

git clean -n

text 复制代码

Would remove cache.tmp
Would remove temp.log

白话翻译： -n 是「假装删」，只告诉你会删什么，不会真动手。

5.5.2 连目录也看

bash 复制代码

git clean -n -d

text 复制代码

Would remove build/
Would remove cache.tmp
Would remove temp.log

白话翻译： -d 连未跟踪的目录也算进来。

5.5.3 真删

bash 复制代码

git clean -f -d

text 复制代码

Removing build/
Removing cache.tmp
Removing temp.log

白话翻译： -f 才是真删。删完就没了，回收站都没有。

验证一下：

bash 复制代码

git status

text 复制代码

On branch main
nothing to commit, working tree clean

干净了。

参数	干什么
`-n`	试运行，不真删
`-f`	强制真删
`-d`	连目录一起删
`-fd`	上述组合（常用）
`-X`	只删 `.gitignore` 里忽略的文件

6. 命令按「用途」分组

6.1 worktree

命令	干什么
`git worktree add ../路径分支`	在新目录检出某分支
`git worktree list`	看当前所有 worktree
`git worktree remove ../路径`	删除某个 worktree

6.2 hooks

钩子	什么时候运行	典型用途
`pre-commit`	`git commit` 之前	lint、格式检查
`prepare-commit-msg`	编辑提交消息之前	自动填模板
`commit-msg`	提交消息写好之后	验证消息格式
`pre-push`	`git push` 之前	跑测试、保护分支

6.3 查和清

命令	干什么
`git blame 文件`	逐行查谁改的
`git blame -L 起始,结束文件`	只看某几行
`git shortlog -sn`	按人统计提交数
`git clean -n`	试运行：看会删什么
`git clean -fd`	真删文件和目录

7. 对照表：降低记忆负担

7.1 worktree vs stash vs 克隆

	`worktree`	`stash`	克隆仓库
同时看两个分支	能	不能	能
共享提交历史	共享	共享	独立（要推拉同步）
占空间	很小	无	整份复制
用完清理	`worktree remove`	`stash drop`	删目录
适合	同时改两个分支	临时藏改动	完全独立干活

7.2 四个常用钩子对照

钩子	拦什么	不满足会怎样
`pre-commit`	代码问题	提交失败
`commit-msg`	消息格式	提交失败
`pre-push`	推送条件	推送失败
`prepare-commit-msg`	没有拦截	只是帮你预填消息

7.3 `clean` 参数记忆

你想干啥	命令
先看会删什么	`git clean -n`
看文件+目录	`git clean -n -d`
确认后真删文件	`git clean -f`
文件+目录一起删	`git clean -f -d`
只删忽略的	`git clean -f -X`

8. 安全习惯

8.1 建议这样做

习惯	原因
worktree 用完就删	目录越积越多容易忘
钩子先在可丢弃仓库试	别一上来就改生产仓库的钩子
钩子脚本加注释	以后回来能看懂
`clean` 永远先 `-n`	删了就没了，不能撤销
`blame` 看完别急着找人	代码可能经过多人之手，最后一人不一定负责
worktree 别检出同分支	Git 会报错，而且逻辑上也不对

8.2 推荐工作流

修紧急 bug 时：

bash 复制代码

# 不用 stash，直接开个 worktree
git worktree add ../hotfix main
cd ../hotfix
# 修 bug、提交
cd ../原仓库
git worktree remove ../hotfix

团队项目加钩子：

bash 复制代码

# 在 .git/hooks/pre-commit 里写检查逻辑
# 或者用 husky 等工具管理（进阶）
# 记住：钩子不会随推送同步，要告诉队友

清理工作区：

bash 复制代码

# 第一步永远先看
git clean -n -d
# 确认没问题再删
git clean -f -d

9. 真实场景

9.1 正在写功能，老师让修 bug

bash 复制代码

# 你在 feature/login 上写登录页
# 老师说 main 有个 bug 要立刻修
git worktree add ../urgent-fix main
cd ../urgent-fix
# 修 bug
printf '修复\n' >> app.py
git add app.py
git commit -m "fix: 紧急修复"
# 修完回到原窗口继续写功能
cd ../lab-extra
# 不需要 stash，不需要切分支

9.2 团队项目要求提交消息规范

bash 复制代码

# 写一个 commit-msg 钩子
cat > .git/hooks/commit-msg << 'SCRIPT'
#!/bin/sh
MSG=$(cat "$1")
if ! echo "$MSG" | grep -qE "^(feat|fix|docs|chore): .+"; then
  echo "提交消息必须以 feat/fix/docs/chore: 开头"
  exit 1
fi
SCRIPT
chmod +x .git/hooks/commit-msg

队友克隆后没有这个钩子------要么手动加，要么用 husky 等工具自动安装。

9.3 期末项目写贡献说明

bash 复制代码

git shortlog -sn

text 复制代码

    12  Ada Example
     8  Bob Example
     3  Carol Example

直接贴进报告：「本组共提交 23 次，其中 Ada 负责 12 次......」

9.4 发现线上 bug，查是谁引入的

bash 复制代码

git blame -L 42,42 app.py

text 复制代码

e7d32aab (Bob Example  2026-07-20 14:30:00 +0800 42) 有bug的那行代码

注意：blame 只查最后改动。如果这行被多人改过，要看完整历史得用 git log -p -- 文件。

9.5 编译后清理产物

bash 复制代码

# 先看有哪些未跟踪文件
git clean -n -d
# 确认都是产物，清掉
git clean -f -d

10. 稍微多懂一点点（可选）

worktree 和子模块不同：worktree 是同一仓库的多工作目录；子模块是嵌入另一个仓库。
服务端钩子 ：pre-receive、update、post-receive 跑在远程服务器上，一般由项目维护者配置，本地开发者碰不到。
钩子可以用任意语言写：只要是可执行脚本就行。Python、Node.js 都可以，第一行写对解释器路径。
git blame 有 -w 参数：忽略空白改动，更准确地追溯逻辑修改。
git clean -X ：只删 .gitignore 里忽略的文件，保留手动创建的未跟踪文件。
worktree 的 .git 是文件不是目录 ：打开看会发现里面只有一行，指向主仓库的 .git 路径。

11. 小实验（请一定动手）

实验甲：worktree 并行操作

建仓，在 main 上提交一次。
git worktree add ../另一个目录 main------会报错（同分支不能同时检出）。
建一个新分支 feature/test，再 git worktree add ../另一个目录 feature/test。
两个目录各改各的、各提交各的。
git worktree list 确认看到两个。
git worktree remove ../另一个目录 清理。

实验乙：让钩子拦住你

写一个 pre-commit 钩子，检查文件里不能有 console.log。
故意提交一个含 console.log 的文件------确认被拦住。
删掉 console.log，再提交------确认通过。
写一个 commit-msg 钩子，要求消息必须包含 # 开头的编号。
试一次不加编号的提交，确认被拦住。

实验丙：blame 和 shortlog

两人（改 user.name 和 user.email 模拟）分别提交几行不同内容。
git blame 文件 看每行是谁写的。
git shortlog -sn 看汇总。

实验丁：clean 安全删除

造 3 个未跟踪文件和 1 个未跟踪目录。
git clean -n -d 看会删什么。
git clean -f -d 真删，确认工作区干净。

通过标准： worktree 建过删过、钩子拦住过你一次、blame 查过人、clean 先 -n 再 -f。

12. 常见问题

问 1：同一个分支能在两个 worktree 里吗？

不能。Git 会报错：「xxx is already checked out at ...」。一个分支只能在一个工作目录里。

问 2：worktree 占多大空间？

很小。只有工作目录占空间，.git 数据库是共享的。

问 3：钩子推送到远程吗？

不会。.git/hooks/ 是本地配置，推送同步不到。想让队友也有钩子，要么文档说明，要么用 husky 等工具。

问 4：钩子可以用 Python 写吗？

可以。脚本第一行写 #!/usr/bin/env python3，然后加上可执行权限就行。

问 5：blame 显示的人不对怎么办？

blame 只显示最后一次改该行的人。可能那行被很多人改过，要看完整历史用 git log -p -- 文件。

问 6：clean 误删了能恢复吗？

不能。没进过 Git 的文件没有被记录，删了就真没了。所以永远先 -n。

问 7：clean -X 和 clean 有啥区别？

-X 只删 .gitignore 里列出的忽略文件；不带 -X 删所有未跟踪文件。

问 8：worktree 删了分支还在吗？

在。删 worktree 只删工作目录，分支上的提交还在仓库里。

13. 总结、学习路线与思维升华

13.1 这一章请记住的

点	记住什么
worktree	同时开两个窗口，`add` 建、`remove` 删
hooks	门口的保安，`.sample` 去掉才生效
pre-commit	提交前自动检查代码
commit-msg	提交前自动检查消息格式
blame	逐行查谁改的
shortlog	按人统计提交数
clean	先 `-n` 再 `-f`，删了就没了

13.2 在整个系列中的位置

text 复制代码

01 认识 Git
02 三区模型
03 基本工作流
04 安全地撤销
05 分支与合并
06 远程协作
07 日常工具
08 新手实验
......
21 额外命令          ← 当前

13.3 思维升华

工具帮你省心，规矩帮你省事。

worktree 让你同时看两条线不再手忙脚乱；hooks 让机器帮你守规矩，不用每次靠自觉。

blame 和 shortlog 让历史不再是一本糊涂账；clean 让工作区保持清爽。

命令不在多，在对的场景用对的那个。

13.4 参考资料

以 Git 2.43.0 验证。演示身份：Ada Example <ada@example.com>。

13.5 本章检查清单

用 worktree add 同时在两个分支上干过活
用 worktree remove 清理过工作目录
写过一个能拦住提交的 pre-commit 钩子
知道去掉 .sample 后缀才能激活钩子
用 blame 查过某一行是谁写的
用 shortlog -sn 看过贡献汇总
用 clean -n 先试运行过，再用 -f 真删

21 — 额外命令：同时开两个窗口、自动检查哨

写在前面：这一章要解决什么

1. 定位：为什么要学「额外命令」

1.1 一句话先记住

1.2 没有它们会怎样

1.3 生活里的类比

1.4 本章内容目标

2. 本质：各管什么

2.1 git worktree：同一仓库的第二个窗口

2.2 Git hooks：门口的保安

2.3 git blame：逐行查作者

2.4 git shortlog：贡献汇总

2.5 git clean：清垃圾

2.6 几条硬规矩

2.7 新手最常踩的坑

3. 建议学习顺序

4. 动手准备

5. 跟着做：每个工具各来一次

5.1 git worktree：同时开两个窗口

5.1.1 再建一个分支当素材

5.1.2 创建 worktree

5.1.3 看看当前所有 worktree

5.1.4 在新 worktree 里干活

5.1.5 用完删掉 worktree

5.2 Git hooks：门口的保安

5.2.1 钩子住在哪

5.2.2 启用 pre-commit 钩子：提交前自动检查

5.2.3 启用 commit-msg 钩子：检查提交消息

5.2.4 pre-push 钩子：推送前检查

5.2.5 prepare-commit-msg 钩子：自动生成提交消息模板

5.2.6 钩子速查

5.3 git blame：谁改了这一行

5.4 git shortlog：贡献汇总

5.5 git clean：清掉没人管的东西

5.5.1 先试运行（不真删）

5.5.2 连目录也看

5.5.3 真删

6. 命令按「用途」分组

6.1 worktree

6.2 hooks

6.3 查和清

7. 对照表：降低记忆负担

7.1 worktree vs stash vs 克隆

7.2 四个常用钩子对照

7.3 clean 参数记忆

8. 安全习惯

8.1 建议这样做

8.2 推荐工作流

9. 真实场景

9.1 正在写功能，老师让修 bug

9.2 团队项目要求提交消息规范

9.3 期末项目写贡献说明

9.4 发现线上 bug，查是谁引入的

9.5 编译后清理产物

10. 稍微多懂一点点（可选）

11. 小实验（请一定动手）

实验甲：worktree 并行操作

实验乙：让钩子拦住你

实验丙：blame 和 shortlog

实验丁：clean 安全删除

12. 常见问题

13. 总结、学习路线与思维升华

13.1 这一章请记住的

13.2 在整个系列中的位置

13.3 思维升华

13.4 参考资料

13.5 本章检查清单

2.1 `git worktree`：同一仓库的第二个窗口

2.3 `git blame`：逐行查作者

2.4 `git shortlog`：贡献汇总

2.5 `git clean`：清垃圾

5.1 `git worktree`：同时开两个窗口

5.2.2 启用 `pre-commit` 钩子：提交前自动检查

5.2.3 启用 `commit-msg` 钩子：检查提交消息

5.2.4 `pre-push` 钩子：推送前检查

5.2.5 `prepare-commit-msg` 钩子：自动生成提交消息模板

5.3 `git blame`：谁改了这一行

5.4 `git shortlog`：贡献汇总

5.5 `git clean`：清掉没人管的东西

7.3 `clean` 参数记忆