name: pm-pr-workflow version: “1.0.0” description: 分支保护和PR创建工作流 when_to_use: PR创建、分支操作、git推送到主分支 category: pm-workflow tags: [git, pr, branch-protection, pm-required]
PR工作流与分支保护
分支保护强制执行
关键: PM必须为主分支强制执行分支保护。
检测（在任何主分支操作前运行）
git config user.email
路由规则
- 用户是
bobmatnyc@users.noreply.github.com→ 可以直接推送到主分支（如果明确请求） - 任何其他用户 → 必须使用特性分支 + PR工作流
用户请求翻译
当非特权用户请求主分支操作时：
| 用户请求 | PM操作 |
|---|---|
| “提交到主分支” | “改为创建特性分支工作流” |
| “推送到主分支” | “分支保护要求PR工作流” |
| “合并到主分支” | “创建PR进行审核” |
错误预防: PM主动引导非特权用户到正确的工作流（不要等待git错误）。
PR工作流委托
默认: 基于主分支的PR（除非用户明确请求堆叠）
当用户请求PR时
- 单个工单 → 一个PR（无需询问）
- 独立特性 → 基于主分支（无需询问）
- 用户说“堆叠”或“依赖” → 堆叠PR（无需询问）
推荐基于主分支当
- 用户未指定偏好
- 独立特性或错误修复
- 多个代理并行工作
- 简单增强
推荐堆叠PR当
- 用户明确请求“堆叠”或“依赖”PR
- 大型特性具有清晰的阶段依赖
- 用户熟悉变基工作流
始终使用策略参数委托给版本控制代理。
PR创建工作流
当创建PR时，委托给版本控制代理：
任务:
代理: "版本控制"
任务: "为{特性}创建PR"
上下文: |
已完成工作: {摘要}
更改的文件: {文件列表}
测试: {测试状态}
QA验证: {qa证据}
验收标准:
- 从主分支创建特性分支
- 将所有提交推送到特性分支
- 创建带有适当描述的PR
- 如果适用，链接工单
- 如果需要，请求审核
常见模式
单特性PR
# 特性分支 → PR → 主分支
feature/user-auth → PR #123 → main
堆叠PR（当请求时）
# 堆叠特性开发
feature/auth-base → PR #123 → main
feature/oauth (基于 auth-base) → PR #124 → feature/auth-base
feature/session (基于 oauth) → PR #125 → feature/oauth
错误修复PR
# 热修复分支 → PR → 主分支
fix/login-error → PR #126 → main
分支保护检查清单
在任何主分支操作前：
- [ ] 检查git用户邮箱
- [ ] 验证用户是否有主分支访问权限
- [ ] 如果不是特权用户，路由到特性分支工作流
- [ ] 创建清晰的分支保护用户消息
与Git文件跟踪集成
所有文件跟踪应在PR创建前在特性分支上进行：
- 代理创建文件
- PM立即跟踪文件（git add + commit）
- PM委托PR创建给版本控制
- 版本控制推送分支并创建PR
这确保所有工作在进入PR工作流前都被跟踪。