AI 时代的单人开发分支范式：轻量 GitHub Flow + 可选 dev

和 AI 一起写代码时，分支管理比以往更重要，不是更不重要。逻辑很简单：main 随时能跑，feature 分支承接所有试验，AI 生成的代码在提交前必须过一遍 diff。

为什么单人开发也需要工作流

使用 Claude Code、Cursor 这类工具，最大的风险不是写不出代码，而是改动范围失控。让它修个 bug，它顺手把配置文件、依赖版本、目录结构全”优化”了；边界条件悄悄变了，表面上代码看起来更”优雅”。三个月后你会发现，那段生成的代码能跑，但没人敢动。

分支工作流解决的正是这个问题：隔离风险、固定稳定点、保持可追溯。AI 可以加快产出，工作流负责限制风险。

两种分支结构

方案 A：main + feature/*，适合大多数项目。改动直接从 feature 合入 main，历史干净，心智负担最小。

main (稳定、可运行)
  ├── feature/login
  └── fix/edge-case

方案 B：main + dev + feature/*，适合经常做大规模重构的项目。dev 作为缓冲区，承接”乱”和”快”，main 只收”稳”和”可交付”。

main (稳定、可发布)
  ↑
dev (集成/试验区)
  ├── feature/refactor-db
  └── feature/ai-rewrite

这个博客项目用的是方案 B：有 Blog Galaxy、Admin 后台、多个工具脚本，AI 辅助大规模重构是常态，dev 分支能挡住很多半成品直接进主干。

开发流程

开始一个新任务，从 dev（或 main）拉新分支：

git switch dev
git pull
git switch -c feature/xxx

分支命名尽量带语义：feature/login、fix/edge-case-null、refactor/db-layer。未来 git log --oneline 一眼知道改了什么，不用考古。

提交时遵循小步原则，每次只做一件事，commit message 说清楚动机：

feat: add xxx
fix: handle xxx
refactor: simplify xxx
chore: bump deps

AI 辅助开发的强制三连

每次让 AI 改完代码，别急着 commit。固定走这三步：

第一步，看 diff。 重点扫依赖文件（package.json、lockfile）、配置文件、大范围重命名和大量删除。这些地方最容易出隐性问题。

git diff

第二步，跑最小验证。 至少跑一次能覆盖主要风险的命令，确认没有低级错误：

npm run build  # 或 npm test

第三步，小步提交。 如果 AI 改动太大，用 git add -p 拆成几次提交，先重构、再功能、再修复。这个命令会让你逐块确认要暂存的改动，非常实用。

ahead by N commits 是什么意思

GitHub 显示 dev is ahead of main by 10 commits，意思就是 dev 里有 10 个提交，main 还没有。把它当成”未发布进度条”就行。

一个实用的经验阈值：ahead 在 5 以内很健康，超过 15 就该找个稳定点合回 main 了，超过 20 后合并和回归的成本会越来越高。

dev 合入 main 的时机：构建是绿的，功能是完整的，你愿意把当前版本交给”未来的自己”。

git switch main
git pull
git merge dev
git push

不要对 dev 做 rebase 改历史，工具和 CI 的记录对不上时会很麻烦。

几个实用工具

切分支前临时保存现场用 git stash，回来再 git stash pop。出问题需要回滚用 git revert <commit_hash>，不改历史，更稳。每次发布或完成较大功能时打个 tag：

git tag v0.1.0
git push --tags

tag 是后续回退时的定位点。出了问题可以直接回退，比翻提交历史快得多。

单人开发也值得开 PR，不是给别人看，而是给三个月后的自己看。PR 描述就是这次改动的操作说明书，强制自己走完验证流程。main 分支保护和 CI 检查哪怕一个人也值得开，能挡住手滑。

几点收获

这套工作流实际用下来，收获不是”流程更规范”这句话本身，而是 main 永远有一个能跑的版本，feature 分支随时可以丢掉重来，AI 生成的代码出了问题也有清晰的回退路径。分支和提交粒度控制好了，git log --oneline 看起来就是一份清晰的开发日志，不是一堆”fix bug”和”update code”。今天多花 5 分钟写好 commit message、拆好提交，未来会省下几小时的考古时间。