与 Git 的工作流：提交信息、PR、代码审查、多分支并行

Git 是 Claude Code 的主场

如果说写代码是 Agent 的职业技能，Git 就是它的办公软件。Claude Code 能看到你的分支、未提交改动和最近提交历史，暂存、提交、建分支、开 PR 全部可以对话化完成。本章按"日常提交 → 审查 → PR → 多线并行"的顺序，给出一套完整的 Git 工作流。

日常提交：从"帮我提交"开始

最基础的用法一句话：

看一下我改了什么，用规范的提交信息提交

它会先跑 git status 和 git diff 看改动，按项目的提交风格写信息，然后暂存提交。注意让它"先总结再动手"——总结部分你能看出它对改动的理解是否正确，理解错了提交信息必然写歪。

想更省事，把提交规范写进 CLAUDE.md：

## Git 约定
- 提交信息：type(scope): 描述，中文描述，英文 type
- 提交前必须跑 npm test
- 禁止 git push --force 到共享分支
- 提交信息尾注保持默认（不手动署名）

几个相关的控制点：提交归属尾注由 attribution 设置控制，内置的 Git 指令可用 includeGitInstructions: false 关掉（都在 settings.json）；"跑 git commit 不要弹窗"则写进权限白名单 Bash(git commit *)。

内置的审查利器：/code-review 与 /security-review

这两个命令是我认为性价比最高的内置能力，交代码前各跑一次是底线动作。

/code-review 审当前 diff 的正确性 bug，也接受 PR 号、分支名或路径：

/code-review              # 审当前改动
/code-review high         # 更高推理强度
/code-review 1234         # 审指定 PR
/code-review --fix        # 审完顺手把问题修了

级别从 low 到 max 控制审查深度；ultra 级别会调动云端多代理做深度审查（Pro/Max 有免费次数）。/security-review 专门找安全问题：注入、鉴权缺陷、数据暴露，审的是你的分支相对远端默认分支的 diff。

配合 /diff（快速过一眼工作区改动）和 /simplify（专审代码能否简化，不找 bug），交付前的三件套齐了。这三件事以前要占用资深同事半小时，现在是你等两分钟的事。

让 Claude 读历史：git log 是破案工具

除了改东西，Git 历史也是 Claude 做侦查的素材库。这几个问法我自己每周都在用：

这段校验逻辑是谁、什么时候加的？当时的提交信息怎么说？
git blame 显示 src/payments/refund.ts 最近三个月有五个人改过，
帮我梳理这块的演变脉络，判断哪次改动引入了现在的重复代码

git log -S（按内容增删搜历史）、git blame、git log -- <文件> 这类考古命令，Claude 都能自主组合使用。考古结果的产出通常是"哪个提交引入了什么"的因果链，比你自己翻网页版 git 平台快得多，还自带分析。

合并冲突：对话式解法

合并冲突是最适合交给 Agent 的 Git 场景之一——它需要"理解两边意图"而不是机械取舍，这正是模型的长项：

main 有新提交，把 feature/payment rebase 上去，有冲突就解决。
原则：冲突时保留 main 侧的接口签名，融合我们侧的新逻辑。
解决完跑一遍 payment 相关测试。

给原则（而不是"你看着办"）是关键。Agent 解决冲突的质量高度依赖你对"谁优先"的表态，一句"接口以 main 为准"就能让它不猜。合并冲突这种活自己干要一小时，Agent 干通常十分钟内交付，而且会把每处取舍讲给你听。

提交拆分与历史整理

另一个被低估的场景：一大批改动要不要拆成多个提交？直接问：

把工作区改动按逻辑单元拆成多个提交：
鉴权相关的放一起，纯格式化的改动单独一个，新依赖升级一个。

它会分析 diff、分组、分别提交。配合 /code-review 先过一遍，这批提交进 PR 时的可读性完全不同于一个千行大提交。reviewer 的体感差异，就是你在团队里的口碑差异。

PR 流程与"PR 即索引"

完整开 PR 的对话流：

总结一下我对鉴权模块的改动
创建 PR
PR 描述里补充安全加固的背景

Claude 会用 gh pr create 之类的工具完成，并且自动把会话和这个 PR 关联。这个关联的价值在于反向查找：claude --from-pr 1234 或在选择器里贴 PR 链接，直接回到"当初做这个 PR 的那场对话"。两周后 reviewer 问"这个改法为什么这么设计"，你一条命令翻出决策现场——这是我重度使用后最喜欢的功能，没有之一。

PR 审查意见来了也不用自己抄：让 Claude 读评论、改代码、推送，一个回合的事。再往后还有自动化的玩法（/autofix-pr 让云端会话盯着 PR 自动修 CI 失败），属于无头模式章节的内容。

多分支并行：worktree 是正解

"一边让 Claude 修 bug，一边自己写功能，结果互相把对方改的文件覆盖了"——这是单目录并行会话的经典事故。解法是 git worktree：每个 worktree 是独立目录、独立分支，互不干扰。

# 一条命令创建 worktree 并在其中启动会话
claude --worktree feature-auth

同一个仓库再开第二个终端跑不同名字，就是两个隔离的并行会话。注意仓库至少要有一个提交，否则命令会报错。会话和 worktree 天然绑定：/resume 选择器里按 Ctrl+W 就能看到所有 worktree 的会话。worktree 里的 gitignore 文件、清理策略，到并行会话那一章细讲。

再补充一个跨工具协同的细节：仓库根目录可以放一个 .worktreeinclude 文件，列出新 worktree 需要复制的 gitignore 文件（比如 .env.local 这类每次 worktree 都要补的配置），新建 worktree 时会自动带上——少一步手工拷贝。

多线任务的路数选择

Git 之上，Claude Code 提供了几种"多线"玩法，先给一张选择表：

新手只需要记住前两行，/batch 这类编排级玩法留到进阶部分再碰。原则是：文件冲突风险决定隔离级别——会改同一批文件的任务必须 worktree 隔离，纯读的任务怎么并都行。

团队协作的边界感

最后说三条团队场景的纪律。第一，git push 和 --force 建议进 deny 白名单或 ask 规则，推送永远是人来按扳机。第二，PR 描述和提交信息让 Claude 起草但人来审——它的文笔没问题，判断力才是你的价值。第三，敏感仓库（涉及凭证、生产配置）把 git add 也收紧，避免误暂存不该进版本库的文件。

再补充两条长期实践心得。其一，把 Git 约定进 CLAUDE.md 而不是每次口头交代：提交信息格式、分支命名、PR 模板位置，写一次受益每个会话，而且新同事装上 Claude Code 就自动继承了这套纪律——这个文件的复利效应在 Git 场景里最明显。其二，别让它替你做主.branch 的命名和删除：分支操作虽然可逆，但误删远端分支的恢复成本不低，保留这几个操作的人工确认是对自己的保护。

Git 工作流的底层事实以官方文档为准；想把审查自动化到每个 PR 上，直接跳读无头模式与 GitHub Actions 那一章。

本章由 WorkBuddy 原创整理，事实性内容参考 Claude Code 官方文档。