我见过最高频的 Claude Code + Git 用法是：改完代码，让 Claude 帮写 commit message。
这没什么问题，但这只是最浅的一层。Git 工作流里有很多节点可以让 Claude 介入，但大多数人只用了最表面的那一个。
你只让 Claude 写 commit message，他让 Claude 做全流程 review。
节点一：commit 之前
commit 前快速 review：
git diff --staged | claude -p "快速 review 这次改动：有没有明显的 bug、遗漏的边界条件、或不一致的地方？中文，不超过五条。"
commit message（按规范）：
git diff --staged | claude -p "按 Conventional Commits 规范写一条 commit message，格式：type(scope): description。只输出 message。"
节点二：PR 描述和 review
自动生成 PR 描述：
git diff main...HEAD | claude -p "生成 PR 描述：改动摘要、技术细节、测试建议、风险点。中文。"
提交前自我 review：
git diff main...HEAD | claude -p "作为 senior engineer review 这个 PR。重点：架构合理性、潜在 bug、性能、安全风险。按严重程度排序。"
节点三：Merge conflict 语义分析
大多数人处理 conflict：看两边代码，选一个，或者手动合并语法。
盲点：语法合并正确，但语义可能是错的。两边各自改了同一段逻辑，机械合并之后逻辑矛盾。
让 Claude 分析：
这是一个 merge conflict：
<<<<<<< HEAD
[你的版本]
=======
[另一个分支的版本]
>>>>>>> feature-branch
两个版本各自做了什么改动？正确的合并方式是什么？
Claude 会分析语义，告诉你是选一边、合并两边逻辑、还是需要重写。
怎么接进日常工作流
从一个节点开始，形成习惯，再扩展：
- commit 前快速 review（最低成本）
- PR 描述自动生成（省时间）
- merge conflict 语义分析（降低合并错误风险）
配合 Hooks，可以把这些节点自动化——commit 前自动触发 review，不需要手动输入命令。
下次处理 merge conflict，把冲突内容粘给 Claude，让它分析语义，而不是手动选 ours/theirs。
你现在在 Git 工作流的哪个节点用了 Claude？欢迎评论区说说。
这是「Claude Code 那些没人告诉你的用法」第十五篇。关注不迷路。
更多 Java 工程实战与 AI 工具内容，欢迎关注公众号：SamLai 效率研习社
