27. Git 工作流

本节目标：学会用自然语言驱动 Git 提交、分支和 Pull Request，掌握 worktree 工作树并行开发的玩法，并了解 Code Review 自动审查怎么帮你把关 PR。

Git 操作也能自然语言驱动

传统用 Git，你得记一堆命令：git add、git commit -m、git checkout -b。在 Claude Code 里，这些命令基本可以「说人话」让它去做。

比如查看改动，直接问：

我改了哪些文件？

最近 10 次提交都改了什么？

Claude 会自动执行对应的 git 命令，把结果讲给你听。提交代码也一样：

把这次的修改提交，commit 信息说明修复了登录验证的 bug

它会根据实际改动自动生成符合规范的提交信息。你不用再为想一句英文 commit message 憋半天。

Tip

让 Claude 提交时，最好用一句话点明「这次改动干了啥」。它写出来的 commit message 会更准，而不是干巴巴的 update files。

分支管理同理，建分支、切分支、合并、删除，都能用自然语言完成：

新建一个 feature/user-profile 分支

切换到 develop 分支

删除已合并的分支

遇到合并冲突，直接说「帮我解决合并冲突」，Claude 会分析冲突内容，根据项目上下文选合适的版本。冲突太复杂时，它会把几个选项的利弊摆给你，让你拍板。

用 worktree 实现并行开发

这是 Claude Code 里我最喜欢的能力之一。

打个比方：你在一个车间里干活（主仓库），现在想同时组装两台不同的机器，但工作台只有一个（当前分支）。要么做完一台再做下一台，要么来回切换零件（切分支）。worktree（工作树）相当于给你加了几个独立工作台，每个工作台摊开自己的零件，互不干扰。

worktree 是 Git 原生的功能，简单说就是「同一个仓库，在不同目录里各检出一份代码，各自有独立分支」。Claude Code 把它做得很顺手。

基本用法

启动时加 --worktree（简写 -w），就会自动创建一个隔离的工作树并在里面开会话：

claude --worktree feature-auth

这会做三件事：

在 .claude/worktrees/feature-auth/ 创建新目录
基于远程默认分支 origin/HEAD 建一个叫 worktree-feature-auth 的新分支
在新目录里启动一个独立的 Claude 会话

想再开一个？换个名字再来一次：

claude --worktree bugfix-123

不指定名字也行，Claude 会自动生成一个有趣的名字，比如 bright-running-fox：

claude --worktree

这样你就能开两个终端，一个建功能、一个修 bug，两边编辑的文件完全不碰彼此。

Warning

记得把 .claude/worktrees/ 加进 .gitignore，不然 worktree 内容会在主仓库里显示成一堆未跟踪文件，看着乱。

基础分支与 PR 分支

默认情况下，worktree 从远程默认分支 origin/HEAD 拉，保证起点干净。如果你 24 小时没 fetch 过，Claude 会先帮你 fetch 一下刷新引用。

有时候你想从当前本地的 HEAD 起，带上还没推送的改动。在 settings.json 里设：

{
  "worktree": {
    "baseRef": "head"
    }
}

baseRef 只接受 "fresh"（默认，从远程）或 "head"（从本地）两个值。

想直接基于某个 PR 分支干活，传一个 # 加 PR 号：

claude --worktree "#1234"

Claude 会从 origin 拉 pull/1234/head，在 .claude/worktrees/pr-1234 建好工作树。特别适合「接着某个 PR 继续改」的场景。

复制 gitignored 文件

worktree 是一份全新检出，所以你主仓库里那些 .env、.env.local 之类的未跟踪文件，工作树里是没有的。项目跑起来会因为缺配置而报错。

解决办法是在项目根目录建一个 .worktreeinclude 文件，语法跟 .gitignore 一样：

.env
.env.local
config/secrets.json

注意：只有既匹配模式、又被 gitignore 的文件才会被复制。已经被 Git 跟踪的文件不会重复。这个机制对 --worktree、子代理 worktree、桌面并行会话都生效。

清理 worktree

退出会话时怎么处理，看你有没有改动：

啥都没改、没提交：worktree 和分支自动删除，干干净净
有改动或提交：Claude 会问你「保留还是删除」，保留的话以后还能回来接着干
用 -p 非交互模式跑的：不会自动清理，得手动 git worktree remove 删

子代理和后台会话建的 worktree，超过 cleanupPeriodDays（清理周期天数，在设置里配）会自动删掉，前提是没有未提交的改动和未推送的提交。

手动管理也完全没问题，直接用原生 Git 命令：

# 在新分支上建 worktree
git worktree add ../project-feature-a -b feature-a

# 列出所有 worktree
git worktree list

# 删掉
git worktree remove ../project-feature-a

子代理隔离

子代理（Subagent）也能用 worktree 隔离。好处是几个子代理并行改文件时不会互相打架。

两种方式：一是直接跟 Claude 说「让子代理用 worktree 来并行处理这些任务」；二是在自定义子代理的 frontmatter 里写死：

---
name: experimental-refactor
description: 在隔离的 worktree 中尝试重构方案
isolation: worktree
tools: Read, Write, Edit, Bash
---

每个子代理会拿到一个临时 worktree，任务完成且没改动时自动删除。

创建 Pull Request

创建 PR 也可以全程自然语言。推荐分三步走：

总结一下我对认证模块做的改动

创建一个 PR

在 PR 描述里补充更多关于安全改进的内容

当 Claude 用 gh pr create 创建 PR 时，会话会自动关联到这个 PR。以后想接着这个 PR 的上下文干活，直接恢复会话即可：

claude --from-pr 123

把 123 换成 PR 编号，或者把 PR URL 粘贴到 /resume 选择器搜索框里也能找到。

Note

Claude 用的是 GitHub CLI（gh）来操作 PR。如果没装 gh，它能读写 GitHub API 但功能有限。建议提前装好 gh 并登录。Claude 常用的命令包括 gh pr create、gh pr view --comments、gh pr diff 等。

Tip

提交前让 Claude 先审查一遍自己生成的 PR，让它把潜在风险和注意事项标出来。自己再扫一眼，比直接合并踏实得多。

自动代码审查 Code Review

Code Review 是一个托管服务，会在你的 GitHub PR 上自动跑代码审查。多个专业代理并行分析差异和周围代码，找逻辑错误、安全漏洞、边界情况破损、微妙的回归问题，然后在内联代码行上发评论。

打个比方：就像给 PR 请了一个不眠不休的资深 reviewer 团队，每个人盯一类问题，还会互相校验、去掉误报，最后把结论写在代码行旁边。

Note

Code Review 目前处于研究预览阶段，仅适用于 Team 和 Enterprise 订阅。想在本地终端直接审查差异、不装 GitHub App 的，看本节最后讲的 /code-review 命令。

严重程度分级

每条发现都带一个严重程度标签：

标记	严重程度	含义
红圆点	重要	合并前应该修的 bug
黄圆点	小问题	轻微问题，值得修但不阻塞
紫圆点	预先存在	代码库里本就有、不是这个 PR 引入的

注意，Code Review 的检查结论永远是「中立」的，不会通过分支保护规则阻止你合并。它只提意见，不挡路。

手动触发审查

不管仓库配的是什么触发方式，你都能在 PR 上评论来手动触发：

命令	作用
`@claude review`	启动审查，并把 PR 订阅到后续每次推送都审查
`@claude review once`	只审查这一次，不订阅后续推送

once 适合那种频繁推送的长周期 PR，你只想要当前状态的一次反馈，不想每次 push 都花钱。

注意命令要作为顶级 PR 评论发布，不是写在差异行的内联评论里。

自定义审查

仓库根目录放两个文件来调教审查行为：

CLAUDE.md：项目通用说明，Claude Code 干所有活都读它。Code Review 会把它当上下文，把新引入的违规标为「小问题」
REVIEW.md：只给审查用的说明，内容会原封不动注入每个审查代理的系统提示里，优先级最高。想改「什么算重要」「跳过哪些路径」「每次最多报几个小问题」，都写这里

一个典型的 REVIEW.md 长这样：

# 审查说明

## 重要在这里的含义
保留重要用于会破坏行为、泄露数据或阻止回滚的发现：
不正确的逻辑、无范围的数据库查询、日志里的 PII。

## 不要报告
- CI 已经强制的：lint、格式化、类型错误
- src/gen/ 下的生成文件和 *.lock 文件

## 始终检查
- 新 API 路由有集成测试
- 日志行不含邮箱、用户 ID 或请求体

Tip

REVIEW.md 越短越管用。写太长反而会稀释最重要的规则。把通用项目上下文留给 CLAUDE.md，REVIEW.md 只放「改变审查行为」的硬性指令。

本地审查 /code-review

不想装 GitHub App、只想在本地终端里审查差异？用斜杠命令（Slash Command）/code-review：

/code-review

默认审查「当前分支相对上游的领先提交」加上工作树里未提交的改动。它报告正确性错误，以及代码复用、简化和效率方面的清理建议。

几个常用变体：

/code-review --comment   # 把发现作为内联 PR 评论发布
/code-review --fix       # 审查后把修复应用到工作树
/code-review main...my-feature  # 审查指定引用范围的差异
/code-review ultra --fix  # 在云端跑更深的 ultrareview 再应用修复

/code-review 还能配合工作量（effort）级别：低级别返回更少、更可信的发现，high 到 max 覆盖更广但可能包含不确定项。

三个实用提醒

第一，worktree 多开是 Anthropic 内部团队公认的提效最佳实践，同时跑 3 到 5 个 worktree，每个开独立会话。但记得定期清理，别让 .claude/worktrees/ 越积越多。

第二，Code Review 按 token 用量计费，单次审查平均 15 到 25 美元，随 PR 大小和复杂度浮动。「每次推送后」触发最贵，「手动」最省钱，按团队节奏选。

第三，复杂的 Git 操作前，可以先切到计划模式（Plan Mode）让 Claude 只读分析、不动手：

claude --permission-mode plan

这样它先把方案摆出来，你确认了再真改，尤其适合合并冲突、大重构这种高风险操作。