个人项目免 PR 直推主分支

入档：2026-07-20 触发：typhoon-eye 文案修改后，AI 按通用安全模板创建 feature 分支 + PR，用户指出”自己改自己审核有点逆天” 验证状态：✅ 已确立为默认规则 性质：Git 协作边界规则，区分个人仓库与协作仓库

一句话

个人项目不要走 PR 流程——自己写代码、自己审核、自己合并，这套仪式没有实际价值，反而拖慢迭代。直接 commit & push 到 main/master 即可。

踩坑现场

2026-07-20 修改 typhoon-eye 风平浪静状态文案后，AI 调用 /commit-push-pr 技能，按默认安全模板执行：

1. 创建 polish-calm-copy feature 分支
2. commit 并 push 到远程
3. 创建 PR #1，附 Summary 与 Test plan
4. 等待”审核”

用户反馈：“自己改自己审核好像有点逆天，你来调整一下。”

随后 AI 将 PR #1 squash 合入 main、删除分支、本地同步。整个 PR 流程在 10 分钟内完成”创建—自审—合并”，没有产生任何信息增量。

为什么个人项目不需要 PR

PR 的核心价值在协作场景才成立

个人项目的真实需求

• 迭代速度优先：改完即推，立即部署/验证
• 历史可读即可：不需要每步都包装成”完整功能”，小步 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隔离的协作陷阱_v1 —— 另一个 AI Git 协作的边界问题
• 复盘事实先行原则_v1 —— 复盘文档写作的事实锚定方法
• 伪开源三查律_v1 —— 开源项目许可证审查
• 2026-10-06_工位池塘v0.6.2_老issue分诊到三端发版_复盘_v1 —— 再用(2026-10-06,desk-pond)：作者在「直推 main / 推分支开 PR」之间选了直推；提交信息里写 Closes #2，推送即关闭 issue

版本

• v1（2026-07-20）：首次确立，基于 typhoon-eye 单次踩坑