名称: 完成开发分支 描述: 当实现完成、所有测试通过时使用，需要决定如何集成工作 - 通过提供合并、PR或清理的结构化选项来指导完成开发工作
完成开发分支
概述
通过提供清晰选项并处理所选工作流来指导完成开发工作。
核心原则: 验证测试 → 提供选项 → 执行选择 → 清理。
开始时宣布: “我正在使用完成开发分支技能来完成这项工作。”
过程
步骤1: 验证测试
在提供选项之前，验证测试通过:
# 运行项目的测试套件
npm test / cargo test / pytest / go test ./...
如果测试失败:
测试失败（<N> 个失败）。必须在完成前修复:
[显示失败]
在测试通过之前无法继续进行合并/PR。
停止。不要继续到步骤2。
如果测试通过: 继续到步骤2。
步骤2: 确定基础分支
# 尝试常见的基础分支
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
或询问: “这个分支是从主分支分离出来的 - 是否正确？”
步骤3: 提供选项
提供以下4个选项:
实现完成。您想做什么？
1. 本地合并回<基础分支>
2. 推送并创建拉取请求
3. 保持分支原样（稍后处理）
4. 丢弃此工作
选择哪个选项？
不要添加解释 - 保持选项简洁。
步骤4: 执行选择
选项1: 本地合并
# 切换到基础分支
git checkout <基础分支>
# 拉取最新
git pull
# 合并功能分支
git merge <功能分支>
# 在合并结果上验证测试
<测试命令>
# 如果测试通过
git branch -d <功能分支>
然后: 清理工作树（步骤5）
选项2: 推送并创建PR
# 推送分支
git push -u origin <功能分支>
# 创建PR
gh pr create --title "<标题>" --body "$(cat <<'EOF'
## 摘要
<2-3 个要点说明更改内容>
## 测试计划
- [ ] <验证步骤>
EOF
)"
然后: 清理工作树（步骤5）
选项3: 保持原样
报告: “保持分支<名称>。工作树保留在<路径>。”
不要清理工作树。
选项4: 丢弃
首先确认:
这将永久删除:
- 分支<名称>
- 所有提交: <提交列表>
- 工作树在<路径>
输入'discard'确认。
等待确切的确认。
如果确认:
git checkout <基础分支>
git branch -D <功能分支>
然后: 清理工作树（步骤5）
步骤5: 清理工作树
对于选项1、2、4:
检查是否在工作树中:
git worktree list | grep $(git branch --show-current)
如果是:
git worktree remove <工作树路径>
对于选项3: 保留工作树。
快速参考
| 选项 | 合并 | 推送 | 保持工作树 | 清理分支 |
|---|---|---|---|---|
| 1. 本地合并 | ✓ | - | - | ✓ |
| 2. 创建PR | - | ✓ | ✓ | - |
| 3. 保持原样 | - | - | ✓ | - |
| 4. 丢弃 | - | - | - | ✓ (强制) |
常见错误
跳过测试验证
- 问题: 合并损坏代码，创建失败的PR
- 修复: 在提供选项前始终验证测试
开放式问题
- 问题: “接下来我该做什么？” → 模糊不清
- 修复: 提供确切的4个结构化选项
自动工作树清理
- 问题: 在可能需要时移除工作树（选项2、3）
- 修复: 仅对选项1和4进行清理
丢弃无确认
- 问题: 意外删除工作
- 修复: 要求输入’discard’确认
红旗
永不:
- 在测试失败时继续
- 未验证结果测试就合并
- 未经确认删除工作
- 无明确请求强制推送
始终:
- 在提供选项前验证测试
- 提供确切的4个选项
- 对于选项4获取输入确认
- 仅对选项1和4清理工作树
集成
被以下调用:
- subagent-driven-development（步骤7） - 在所有任务完成后
- executing-plans（步骤5） - 在所有批次完成后
配合使用:
- using-git-worktrees - 清理由该技能创建的工作树