---
title: 第 8 章 Git、Worktree、Cloud 与多 Agent 协作
seo:
  title: "Git、Worktree 与多 Agent 协作实践"
description: "全面讲解Git最小纪律、Worktree并行开发、环境复制、Cloud与Routine部署、GitHub/GitLab协作以及多Agent合并协议等实践方法。"
---

Agent 不替代 Git。它最擅长把需求、代码、测试、Diff、PR 和发布说明串成闭环；并行能力只有建立在分支隔离和合并纪律上才有价值。

## 8.1 本地 Git 的最小纪律

- 任务开始前：确认 `git status`、当前分支、未提交改动与远端差异。
- 复杂任务：新建分支或 worktree；不要让两个 Agent 同时写同一个工作目录。
- 执行中：按里程碑形成小 Diff；测试通过再进入下一步。
- 提交前：Agent 总结改动、风险、未验证项和回滚；人类审阅实际 Diff。
- 合并前：CI、review、回归与变更说明必须通过；Agent 建议不能替代保护分支。

## 8.2 Worktree：最稳妥的并行起点

| **模式** | **任务拆分** | **适合** | **注意** |
|----|----|----|----|
| **1 主 1 辅** | 主会话实现，辅会话写测试或 review | 第一次并行 | 避免同时改相同文件 |
| **按模块** | 前端、后端、文档、迁移各自 worktree | 边界清晰的功能 | 先约定接口与合并顺序 |
| **研究 / 实现 / 验证** | 研究员只读，实施者写代码，验证者跑应用 | 复杂需求 | 以 SPEC 和证据文档汇总 |
| **后台队列** | 多个独立 issue 各自 worktree / cloud | 批量维护 | 限制并发、磁盘与 CI 消耗 |

Worktree 三种入口：

```bash
# Claude Code：在隔离工作树中启动
claude --worktree feature-order-export

# Codex：可在桌面项目中为聊天选择 Worktree
# CLI / 客户端具体入口以当前版本为准

# 原生 Git 方案（工具无关）
git worktree add ../repo-feature-order-export -b feature/order-export
cd ../repo-feature-order-export
```

## 8.3 环境复制与依赖一致性

| **问题** | **表现** | **处理** |
|----|----|----|
| **`.env` 未进入 worktree** | 服务启动失败 | 使用受控复制清单、密钥管理器或启动脚本；不要提交真实 .env |
| **依赖目录不一致** | 构建慢或版本漂移 | 使用 lockfile、共享缓存或容器；不要复制未知 node_modules |
| **本地端口冲突** | 多个会话抢同一端口 | 参数化端口、使用 compose project name 或临时环境 |
| **数据库状态冲突** | 迁移互相覆盖 | 每个工作树使用独立 schema / database 或只生成迁移 |
| **生成文件冲突** | 合并时大量噪音 | 明确唯一生成顺序；在 CI 中重生成并校验 |

## 8.4 Codex Cloud 与 Claude 云端 / Routine

| **比较** | **Codex Cloud** | **Claude Routines / 云端会话** |
|----|----|----|
| **核心价值** | 配置可复现环境，提交并行编码任务，审阅结果后应用到本地 | 以计划、API、GitHub 等触发云端或自托管会话 |
| **适合** | 长时间实现、批量 issue、离线继续、统一依赖 | 周期性维护、事件触发、跨工具流程 |
| **前置** | 连接仓库、配置环境、密钥、网络和测试 | 配置 routine、触发器、执行环境、权限和通知 |
| **风险** | 云端数据、环境漂移、并发成本、结果合并 | 研究预览变化、事件重复、速率限制、幂等 |

## 8.5 GitHub / GitLab 协作

| **环节** | **适合交给 Agent** | **必须由团队制度决定** |
|----|----|----|
| **Issue** | 澄清假设、拆任务、生成验收 | 优先级、责任人、业务决策 |
| **实现** | 按 SPEC 改代码、写测试、运行命令 | 架构边界、依赖策略、数据风险 |
| **PR 描述** | 背景、改动、风险、测试、回滚草稿 | 是否完整、是否可合并 |
| **Code Review** | 发现逻辑、安全、测试与可维护性问题 | 严重度、阻断标准、最终批准 |
| **CI** | 解释失败、提出修复、生成重复检查 | 门禁规则、凭据、生产发布 |
| **Release** | 生成 changelog、迁移与回滚说明 | 发布窗口、审批、监控与事故责任 |

:::note[GitLab 状态提醒]
截至本讲义基线，Codex 的部分 GitLab 集成标注为 Beta；Claude Code 也在持续扩展 GitLab MR 与 Marketplace 支持。培训演示应以目标组织实际启用能力为准。
:::

## 8.6 可复制的 PR 流程

1. PM / 开发者提交包含目标、范围、验收和非目标的 Issue 或 SPEC。
2. Agent 在 Plan 模式分析影响面；人类确认后创建分支 / worktree。
3. Agent 实现最小闭环并运行测试；失败时保留日志和原因。
4. 独立 reviewer Agent 读取 Diff，优先检查权限、异常、数据与测试缺口。
5. 实施 Agent 修复；验证 Agent 运行回归和浏览器走查。
6. Agent 生成 PR 描述与回滚说明；人类审阅并 push / 创建 PR。
7. CI 与人类 reviewer 通过后合并；踩坑回填规则、Skill 或测试。

## 8.7 多 Agent 的合并协议

| **必须明确** | **推荐格式** |
|----|----|
| **任务所有权** | 每个 Agent 只有一个清晰输出和可写文件范围 |
| **接口契约** | 输入、输出、数据结构、错误语义、兼容要求 |
| **合并顺序** | 基础接口 → 实现 → 测试 → 文档；有依赖时不得并行强推 |
| **冲突解决** | 由一个主会话 / 人类负责集成，不让两个 Agent 互相覆盖修冲突 |
| **验证责任** | 每个 Agent 验证自己的输出；主会话做端到端回归 |
| **状态回报** | Done / Blocked / Needs decision / Not verified 四种状态 |