这篇继续围绕 Claude Code 展开，主题是「Claude Code 配合 Git 怎么用？分支、diff、提交前检查一条线」。前面几篇已经讲过安装、settings.json、-p 模式和 CLAUDE.md，这次往真实使用流程里再拆细一点。
Git 是 AI 编程的安全网
一旦让 Claude Code 改你的代码，Git 就不再是「版本管理工具」那么简单，而变成了「随时回滚的安全网」。所以即使是小白，也建议把 Git 工作流先理顺，再放手让 AI 跑。
第一步：开一个独立分支
让 Claude Code 改代码前，先开一个独立分支：
git checkout -b feat/ai-refactor-login
这一步看起来多余，实际上非常关键。它让你随时可以：
- 把 AI 改的整块工作丢掉，不影响主干
- 在不同分支上对比效果
- 把 AI 的工作单独 PR，方便 review
不要让 Claude Code 直接在 main 上动手，这是一条死规矩。
第二步：让它先说改动计划
在动代码之前，让模型先用自然语言列出：
- 准备改哪些文件
- 每个文件大概改什么
- 是否要新增依赖
这个「改动计划」相当于 PR 描述的草稿。你看完觉得方向不对，可以立刻打住。
第三步：每一步都看 diff
Claude Code 改完代码以后，第一时间运行：
git diff
或者用 IDE 的 diff 面板。这一步千万别省。你要看的不是「跑不跑得起来」，而是：
- 有没有偷偷改无关代码
- 有没有删掉看似没用其实关键的代码
- 有没有引入奇怪的依赖或路径
AI 改的代码，能跑不代表对。diff 是你和 AI 之间最低成本的沟通方式。
第四步：让它写 commit message，但你审
写 commit message 是 Claude Code 擅长的事情。你可以让它根据 diff 自动生成：
根据当前 diff，写一条符合 Conventional Commits 规范的提交信息
它生成的通常质量不错，但要注意两点：
- 类型选对了吗（feat / fix / refactor / chore）
- 描述有没有夸大改动范围
AI 有时会把一个小修复写成「重大优化」，需要你手动收一下。
第五步：不要让它自动 push
这是我个人坚持的一条原则：不让 Claude Code 自动 push 到远端。原因很简单：
- push 之后回滚成本高
- 万一推到 main，会污染远端历史
- CI 资源会被无意义触发
你可以在 settings.json 里限制 git push 的权限，或者干脆把整个 push 步骤留给人来做。
第六步：用 PR 审一遍
哪怕只是个人项目，也建议开 PR。PR 页面的 diff 比本地终端清楚得多，还能让 Claude Code 帮你写 PR 描述：
根据这次分支的所有提交，帮我写一段 PR 描述，分「改动动机」「主要改动」「测试方式」三段。
一条理想的工作流
串起来大概是这样：
git checkout -b新分支- 让模型列改动计划
- 让模型动手改
git diff审查- 让模型写 commit message
- 手动
git push - 开 PR，让模型写描述
- 自己再审一遍合并
小结
Claude Code 不是 Git 的替代品，而是 Git 之上的助手。分支隔离、diff 必看、push 留给人——这三条守住，AI 写代码的安全感会高一个档次。
延伸阅读
如果你还没看前面的基础篇，可以先看《Claude Code 从零搭建》《settings.json 权限配置》《CLAUDE.md 项目规则》这几篇，再回来看本文会更顺。
小结
Claude Code 真正好用的地方，不是让它一次性替你完成所有事，而是把流程拆清楚：哪些让 AI 做，哪些必须人来确认，哪些结果要留下验证记录。这个习惯养成之后，它就更像一个靠谱的编程搭档。
