自动提交
改完代码直接说：
> 提交这些修改
Claude Code 会：
git diff查看所有改动- 分析改动内容，生成语义化的 commit message
- 只 stage 相关文件（自动跳过
.env、node_modules等敏感文件） - 展示 commit 预览，等你确认后执行
生成的 commit message 格式规范，比如：
feat: add input validation to user registration form
- Add email format check with regex
- Add password strength requirements
- Show inline error messages on invalid input
创建 PR：从命令到上线
基本用法
> 创建一个 PR，目标分支 main，描述这次改了什么
Claude Code 会自动生成 PR title 和 description，包括：
- 改动摘要（从 diff 提炼）
- 影响范围
- 测试说明
- 关联的 issue（如果 commit message 里有
#123引用）
接 GitHub MCP Server 之后
配置好 GitHub MCP Server（见第 5 章），PR 创建变成真正的一步操作：
> 我这个功能分支做完了，帮我推到 remote，然后对 main 开 PR，
标题写「feat: 用户个人资料页改版」，reviewer 加上 @alice @bob
Claude Code 完成的步骤：
git push -u origin feature/user-profile- 调用 GitHub API 创建 PR，填写 title 和 body
- 通过 API 添加 reviewer
- 返回 PR 链接
整个过程不需要离开终端，也不用在浏览器里填表单。
用模板生成 PR Description
如果项目里有 .github/pull_request_template.md，直接告诉 Claude Code 按模板填：
> 按 PR 模板创建，测试这块写「单元测试 + 手动测试 iOS Safari 14」，
风险评估写「涉及登录逻辑，建议先部署到 staging 验证」
它会把你说的内容映射到模板对应字段，其余字段从代码改动里自动提取。
PR 创建后的跟踪
有了 GitHub MCP，这些查询直接走 API，不用去浏览器刷页面：
> 我的 PR #234 CI 跑了多久？测试有没有过？
> PR #234 有什么 review 意见还没处理？
> PR #234 被 approve 了吗？帮我 merge 掉
分支管理
# 创建功能分支
> 从 main 创建一个新分支 feature/user-profile，然后切过去
# 查看分支状态
> 当前分支和 main 差了几个 commit？有没有冲突？
# 合并前检查
> 帮我 rebase 到最新的 main，如果有冲突就告诉我
实战场景：hotfix
线上出 bug 时，Claude Code 能帮你从排查到修复到提 PR 全流程搞定：
> 线上 /api/users 接口返回 500，这是错误日志：
> [粘贴日志]
> 帮我找到原因，修复，然后创建 hotfix PR
Claude Code 的执行流程：
- 分析错误日志，定位到具体的代码文件和行号
- 读取相关代码，理解上下文
- 找到 root cause 并修复
- 跑测试确认修复有效
- 创建 hotfix 分支、提交、推送、创建 PR
从发现 bug 到 PR ready，通常 5 分钟内完成。
解决 Merge Conflict
快速解决
> 帮我解决当前的 merge conflict
Claude Code 会读取冲突文件，理解两边的改动意图，选择合理的合并策略。对于复杂冲突，它会解释每处冲突的取舍理由，让你做最终决定。
详细工作流
实际的 merge conflict 处理分三步走：
第一步：搞清楚冲突来源
> git status 看一下，哪些文件有冲突？每个冲突大概是什么类型的改动？
Claude Code 会逐一分析冲突标记（<<<<<<< / ======= / >>>>>>>），判断是：
- 同一行被两边都改了（真冲突，需要人工决策）
- 两边改了不同函数（可以安全合并）
- 一边删文件、另一边修改了同一文件（最复杂，需要理解业务意图）
第二步：解决每个冲突
对于简单情况，让它直接解决：
> src/components/Header.tsx 那个冲突，用 main 分支的版本
> src/utils/api.ts 那里两边的修改都要保留，帮我合并
对于复杂冲突，让它解释后你来决定：
> UserService.java 有三处冲突，帮我逐一分析，告诉我每处用哪边更合理，
但别直接改，等我确认
第三步：验证合并结果
> 冲突都解决了，帮我跑一下测试，看看有没有引入新问题
常见陷阱
package-lock.json / yarn.lock 冲突：这类文件手工合并必出错。正确做法：
> package-lock.json 有冲突，帮我选一个版本 checkout，然后重新 npm install 生成
Claude Code 会 checkout 某一边的版本，再跑 npm install 重新生成 lockfile，结果一定是正确的。
Rebase 中途冲突：rebase 过程中遇到冲突会停下来，可以这样接着处理：
# rebase 停在某个 commit，告诉 Claude Code
> rebase 暂停了，当前冲突是什么情况？帮我解决，然后 git rebase --continue
Git Worktree 配合 Claude Code
为什么需要 worktree
开发时常见场景：你在 feature/checkout-v2 上改了一半，突然要去修一个生产 bug。常规做法是 git stash，切分支，改完再切回来、git stash pop。如果两个任务都需要 Claude Code 介入，两个 session 会互相干扰，stash/unstash 也容易出错。
git worktree 让你在同一个仓库里有两个独立的工作目录，各自对应不同分支，互不干扰。
基本用法
# 给 hotfix 任务开一个独立工作目录
git worktree add ../my-project-hotfix hotfix/payment-bug
# 在新工作目录里启动 Claude Code
cd ../my-project-hotfix
claude
两个终端窗口，两个 Claude Code session，分别处理不同任务，git 状态完全隔离。
让 Claude Code 帮你管理 worktree
> 用 git worktree 给我创建一个新工作目录处理 hotfix，
分支名 hotfix/fix-cart-total，目录放在 ../jr-shop-hotfix
Claude Code 执行：
git worktree add -b hotfix/fix-cart-total ../jr-shop-hotfix main
任务完成后清理：
> worktree 任务搞完了，帮我合并回 main 然后删掉那个 worktree
Claude Code 依次执行：
# 提交 worktree 里的改动
git -C ../jr-shop-hotfix add .
git -C ../jr-shop-hotfix commit -m "fix: correct cart total calculation"
# 回到主目录合并
git checkout main
git merge hotfix/fix-cart-total
# 清理
git worktree remove ../jr-shop-hotfix
git branch -d hotfix/fix-cart-total
多 agent 并行任务
Claude Code 的 Agent SDK 里，isolation: "worktree" 选项会自动为每个子 agent 创建独立 worktree，任务结束后自动清理。这是在 CI / 自动化流水线里跑多个并发 agent 的推荐方式——每个 agent 有自己的文件系统视图，不会踩脚：
// 两个 agent 同时工作，互不干扰
const [refactorResult, testResult] = await Promise.all([
claude.run("重构 UserService", { isolation: "worktree" }),
claude.run("补充单元测试", { isolation: "worktree" }),
]);
详见第 8 章 Agent SDK 的隔离模式。
代码审查
让 Claude Code 在提交前帮你检查代码质量：
> review 一下我这次改的所有文件，看有没有问题
它会检查：
- 逻辑错误和边界情况
- 类型安全问题
- 潜在的性能问题
- 不符合项目规范的写法
安全机制
Claude Code 对 Git 操作的默认行为很保守：
- 不会自动 push，修改都先到本地
- 不会 force push 或
reset --hard - 不会跳过 pre-commit hook（
--no-verify） - 敏感文件（
.env、credentials）不会被 stage
这些限制确保你不会因为 AI 的一次操作搞坏远程仓库。如果某个操作确实需要 force push，你需要明确告诉它。
