个人项目免 PR 直推主分支 v1
入档：2026-07-20 触发：typhoon-eye 文案修改后，AI 按通用安全模板创建 feature 分支 + PR，用户指出”自己改自己审核有点逆天” 验证状态：✅ 已确立为默认规则 性质：Git 协作边界规则，区分个人仓库与协作仓库
一句话
个人项目不要走 PR 流程——自己写代码、自己审核、自己合并，这套仪式没有实际价值，反而拖慢迭代。直接 commit & push 到 main/master 即可。
踩坑现场
2026-07-20 修改 typhoon-eye 风平浪静状态文案后，AI 调用 /commit-push-pr 技能，按默认安全模板执行：
- 创建
polish-calm-copyfeature 分支 - commit 并 push 到远程
- 创建 PR #1，附 Summary 与 Test plan
- 等待”审核”
用户反馈：“自己改自己审核好像有点逆天，你来调整一下。”
随后 AI 将 PR #1 squash 合入 main、删除分支、本地同步。整个 PR 流程在 10 分钟内完成”创建—自审—合并”，没有产生任何信息增量。
为什么个人项目不需要 PR
PR 的核心价值在协作场景才成立
| 价值 | 协作项目 | 个人项目 |
|---|---|---|
| 代码审核，防止低质量代码进入主分支 | ✅ 多人互审有必要 | ❌ 作者即审核者，无增量 |
| 讨论与决策留痕 | ✅ 跨时区/跨角色沟通 | ❌ 作者自己知道为什么 |
| CI 自动化检查 | ✅ 保护主干稳定性 | 🟡 可直接在 main 上跑，失败再修 |
| 版本历史整洁 | ✅ rebase/squash 保持线性 | 🟡 个人项目容忍小步快跑 |
个人项目的真实需求
- 迭代速度优先：改完即推，立即部署/验证
- 历史可读即可：不需要每步都包装成”完整功能”，小步 commit 反而更真实
- 减少认知负担：不用想”这个功能要不要开分支”，专注在代码本身
规则边界
✅ 个人项目：直推 main
- 仓库 owner 只有本人
- 无其他协作者需要 review
- 无严格发布窗口或合规要求
操作：
git add -A
git commit -m "描述"
git push origin main⚠️ 协作/公司项目：必须走 PR
- 多人共同维护
- 有 code owner / 保护分支规则
- 需要审计留痕或合规审核
- 有 CI/CD 门禁，必须通过检查才能合并
操作：feature 分支 → PR → review → squash/merge → 删除分支
🟡 灰色地带：个人但对外开源的项目
如果个人项目开始接受外部 contributor：
- 对外部 PR：走正常 review 流程
- 对自己的改动：仍可直推 main，但建议养成写清楚 commit message 的习惯（外部人会看历史）
给 AI 的指令模板
当用户说”commit and push”且项目是个人仓库时：
直接 add、commit、push 到 main，不要创建 feature 分支和 PR。判断依据（满足任一即可）：
- 用户明确说过”个人项目不走 PR”
- 仓库无其他 collaborator
- 仓库无分支保护规则
- 用户历史习惯均为直推 main
关联文档
- ⭐ 生成物不入git_v1 —— 同族 git 纪律的另一半：本条管”提交流程别过度仪式化”，那条管”提交内容别塞生成物”（PDF/构建包入历史后体积降不回来）
- Claude_Code_Worktree隔离的协作陷阱 —— 另一个 AI Git 协作的边界问题
- 复盘事实先行原则 —— 复盘文档写作的事实锚定方法
- 伪开源三查律_v1 —— 开源项目许可证审查
版本
- v1（2026-07-20）：首次确立，基于 typhoon-eye 单次踩坑