solo-parallel-dev

name	solo-parallel-dev
description	单人多分支并行开发工作流：一个人同时开发多个feature/fix/docs时，如何管理分支、预防冲突、恢复上下文、有序合并。当用户说'同时开发几个功能'、'多分支并行'、'分支管理'、'切来切去忘了进度'、'README冲突'、'一个人怎么并行开发'时触发。核心特点：worktree物理隔离、分支状态看板、冲突预防策略、上下文恢复协议、合并排序算法。

来源: 自建（基于 skills-ai 仓库 94 个 skill 的实战经验）

发布时间: 2026-05-25

理念: "一个人开 5 个分支，不等于 5 倍效率——等于 5 倍混乱。"

🌿 Solo Parallel Dev — 单人多分支并行开发工作流

你既是产品经理，也是开发，也是 QA，也是运维。

这个 Skill 教你如何在不把自己逼疯的前提下，一个人并行推进多个 feature。

---

🎯 核心原则

原则1: 并行 ≠ 同时写代码
  真正的并行是"A 在等反馈时做 B"，不是"A 写到一半切去做 B"

原则2: 同时活跃的分支 ≤ 3 个
  人脑上下文切换的成本极高，超过 3 个必烂尾

原则3: main 分支永远可部署
  你自己就是唯一的 gatekeeper，不要骗自己

原则4: 用 worktree 物理隔离，不用 stash  mentally 隔离
  stash 会让你忘记，worktree 让你打开文件夹就回到上下文

---

🏗️ 分支策略

分支命名规范

feat/<skill-name>-<简短描述>     # 新功能
fix/<bug-desc>                    # 修复
docs/<doc-update>                 # 文档更新
refactor/<scope>                  # 重构
chore/<maintenance>               # 维护性工作

示例：
  feat/backend-change-flow-upgrade
  feat/ai-collaboration-safety
  fix/readme-typo
  docs/cross-platform-guide

分支生命周期状态

🌱 新建    → 刚创建，还没写代码
🌿 开发中  → 正在编码，有未提交变更
🍃 暂存中  → 开发中断，已 stash / 已提交但未完
🌳 待合并  → 代码完成，等待合入 main
🍂 已归档  → 已合并到 main，可删除

---

🛠️ 工作流：worktree 物理隔离法（推荐）

为什么用 worktree 而不是 stash / 反复 checkout？

方式	切换成本	上下文保留	同时查看多个分支
git checkout	中	差（靠记忆）	❌ 不能
git stash	低	极差（经常忘）	❌ 不能
git worktree	低	极好（物理隔离）	✅ 可以

worktree 设置

# 主仓库（main 分支）
cd /d/xgq/work/skills-ai

# 为每个 feature 创建独立工作目录
git worktree add ../skills-ai-feat-backend-flow feat/backend-change-flow-upgrade
git worktree add ../skills-ai-feat-ai-safety feat/ai-collaboration-safety
git worktree add ../skills-ai-fix-readme fix/readme-typo

# 查看所有 worktree
git worktree list

# 输出：
# D:/xgq/work/skills-ai            main       [main]
# D:/xgq/work/skills-ai-feat-backend-flow  feat/backend-change-flow-upgrade  [feat/backend-change-flow-upgrade]
# D:/xgq/work/skills-ai-feat-ai-safety     feat/ai-collaboration-safety      [feat/ai-collaboration-safety]

目录结构：

D:\xgq\work\
├── skills-ai/                    # main 分支，稳定版本
├── skills-ai-feat-backend-flow/  # feat/backend-change-flow-upgrade
├── skills-ai-feat-ai-safety/     # feat/ai-collaboration-safety
└── skills-ai-fix-readme/         # fix/readme-typo

切换上下文 = 打开另一个 VS Code 窗口，不需要 stash，不需要记 stash 里是什么。

---

📋 分支状态看板（Branch Kanban）

你自己维护一个看板文件，防止遗忘。

看板位置

skills-ai/
├── .solo-dev/                    # 新建这个目录
│   └── BRANCH_KANBAN.md          # 分支状态看板

这个文件只在 main 分支维护，每个 feature 分支不修改它。

看板模板

# 🌿 单人并行开发看板

## 当前活跃分支（最多 3 个）

| 分支 | 状态 | 目标 | 进度 | 阻塞点 | 下一步 |
|------|------|------|------|--------|--------|
| feat/backend-change-flow-upgrade | 🌿 开发中 | 升级七阶段闭环 + AI安全机制 | 阶段⑤编码中 | 等用户确认原子输出规则 | 完成编码，提PR |
| feat/ai-collaboration-safety | 🌳 待合并 | 新建防逼疯Skill | 100% | 无 | 提PR → 合并 |
| fix/readme-typo | 🌳 待合并 | 修复README格式错误 | 100% | 无 | 随时可合 |

## 待开始（Backlog）

| 分支 | 优先级 | 预估工作量 | 依赖 |
|------|--------|-----------|------|
| feat/weather-skill-v2 | P1 | 2天 | 无 |
| feat/frontend-code-review-v2 | P2 | 1天 | 等设计稿 |

## 已归档

| 分支 | 合并日期 | 说明 |
|------|---------|------|
| feat/music-recommender | 2026-05-22 | 音乐推荐Skill |
| feat/cardiac-arrest-guide | 2026-05-20 | 心脏骤停急救指南 |

更新时机：

• 每次切换分支前 → 更新当前分支的"进度"和"阻塞点"
• 每次合并后 → 移动到"已归档"
• 每周一 → 审视看板，清理烂尾分支

---

🔄 上下文恢复协议（Context Recovery）

场景：你三天前在分支 A 写了一半，今天切回来，完全不记得当时在想什么。

恢复三步法

Step 1: 读取分支看板

cat .solo-dev/BRANCH_KANBAN.md
# 找到分支 A 的"进度"和"阻塞点"

Step 2: 读取分支内的进度笔记

每个 feature 分支根目录下放一个 BRANCH_NOTES.md：

# 分支笔记：feat/backend-change-flow-upgrade

## 当前焦点
- 正在写阶段⑤的"原子输出协议"部分
- M03 修改点已完成，M04 写到一半

## 关键决策记录
- 2026-05-25: 决定原子输出每次只输出一个方法，而非一个文件
- 2026-05-25: 熔断阈值定为"同一修改点错3次"

## 待确认问题
- [ ] 阶段⑦的"AI盲区清单"格式是否合适？
- [ ] 是否需要和 ai-collaboration-safety 交叉引用？

## 上次离开时的状态
- git status: 有 2 个未暂存文件（backend-change-flow/SKILL.md 修改中）
- 未解决：README.md 还没更新

Step 3: 查看代码状态

git status
git diff          # 看看上次改到哪了
git log --oneline -3  # 看看上次提交是什么

如果用了 worktree：

• 打开对应文件夹 → 文件就躺在那里
• VS Code 的未保存标签页还在（如果你没关窗口）
• 终端历史记录还在（history | tail -20）

---

⚔️ 冲突预防策略

单人并行最恶心的冲突：自己改 A 分支的 README，同时改 B 分支的 README，合并时自己和自己冲突。

策略 1：公共文件延迟修改

❌ 错误：每个 feature 分支都改 README.md
  → feat/A 改了技能数 93→94
  → feat/B 改了技能数 93→95
  → 合并冲突，自己打自己

✅ 正确：feature 分支里 README.md 要么不改，要么只改目录结构树（不碰统计数字）
  → feat/A 的 README 保持 93 个
  → feat/B 的 README 保持 93 个
  → 合并到 main 后，统一改一次 93→95

具体规则：

文件	feature 分支能否改	处理方式
SKILL.md（本分支的）	✅ 必须改	正常开发
README.md 目录结构树	⚠️ 谨慎改	只添加本分支的目录行，不改其他行
README.md 技能总数统计	❌ 不改	留到合并后再改
README.md 分类表格	⚠️ 谨慎改	只添加本分支的行，不改表头
README.md 维护记录	❌ 不改	留到合并后再追加

策略 2：合并前统一刷新（Reconciliation）

所有 feature 开发完成后，创建一个 chore/reconcile-readme 分支：

# 1. 从最新 main 切出
git checkout main
git pull origin main
git checkout -b chore/reconcile-readme

# 2. 统一修改 README 的所有统计数字
# 3. 统一整理目录结构树
# 4. 统一追加维护记录

# 5. 提一个单独的 PR："docs: 统一更新 README 统计信息"

策略 3：先合小的，后合大的

合并顺序影响冲突量：

推荐顺序：
1. fix/* 分支（改动小，先合，减少后续冲突面）
2. docs/* 分支（改动中，无逻辑变更）
3. feat/* 分支（按改动量从小到大）
   → feat/小功能（改 2 个文件）
   → feat/中功能（改 5 个文件）
   → feat/大功能（改 10+ 个文件，重构级）

原因：

• 小分支先合入 main → main 更新 → 大分支 rebase 到最新 main → 大分支解决冲突
• 如果大分支先合 → 小分支 rebase 时要解决大分支引入的冲突，亏死

---

📦 合并策略

单人推荐：Rebase + Fast-forward（保持线性历史）

# 假设要合并 feat/ai-collaboration-safety

# 1. 确保 main 最新
git checkout main
git pull origin main

# 2. 切到 feature 分支，rebase 到最新 main
git checkout feat/ai-collaboration-safety
git rebase main
# （如有冲突，在本分支解决，不污染 main）

# 3. 切回 main，快进合并
git checkout main
git merge feat/ai-collaboration-safety --ff-only

# 4. 推送
git push origin main

# 5. 清理
git branch -d feat/ai-collaboration-safety
git push origin --delete feat/ai-collaboration-safety

如果 feature 分支已经 push 到远程（有 PR）

# 用 squash 合并，保持 main 历史干净
git checkout main
git merge feat/xxx --squash
# 生成一个干净的提交

git commit -m "feat: xxx

- 功能点1
- 功能点2

Closes #PR编号"

---

🧹 防烂尾机制

一个人最容易犯的错误：开了 5 个分支，3 个烂尾。

烂尾识别信号

信号	说明	处理
分支超过 7 天无提交	大概率已忘记上下文	要么强制恢复，要么删除
分支看板状态为"暂存中"超过 3 天	阻塞点没解决	评估是否值得继续，或降级为 backlog
分支里有大量 WIP 提交	"save point"式提交	rebase -i 整理提交历史再合
分支目标变得不清晰	做着做着忘了初衷	回看最初的 issue / 需求描述

每周清理仪式（Monday Cleanup）

# 1. 列出所有本地分支
git branch -v

# 2. 识别烂尾分支
#    - 超过 7 天未动
#    - 最后一次提交是 WIP / save / temp

# 3. 对每个烂尾分支做决策：
#    A. 继续 → 执行上下文恢复协议
#    B. 废弃 → git branch -D <branch>
#    C. 降级 → 移动到 backlog，不活跃处理

# 4. 更新 BRANCH_KANBAN.md

---

🚀 完整工作流示例

场景：你要同时开发 3 个 feature

Feature A: 升级 backend-change-flow（大，2天）
Feature B: 新建 ai-collaboration-safety（中，1天）
Feature C: 修复 README typo（小，10分钟）

Day 1 上午：

# 创建 worktree
git worktree add ../skills-ai-feat-a feat/backend-change-flow-upgrade
git worktree add ../skills-ai-feat-b feat/ai-collaboration-safety
git worktree add ../skills-ai-feat-c fix/readme-typo

# 更新 BRANCH_KANBAN.md
# 状态：A-开发中，B-新建，C-新建

Day 1 上午-下午：在 skills-ai-feat-c 里修 typo

cd /d/xgq/work/skills-ai-feat-c
# 改代码 → git commit → push
# 状态更新：C-待合并

Day 1 下午：合入 C，开始 B

# 合入 C
cd /d/xgq/work/skills-ai
git checkout main && git pull
git merge fix/readme-typo --ff-only && git push

# 开始 B
cd /d/xgq/work/skills-ai-feat-b
# 开发 ai-collaboration-safety
# 状态更新：C-已归档，B-开发中

Day 1 晚上：B 完成，A 开了个头

# B 完成
cd /d/xgq/work/skills-ai-feat-b
git commit → push
# 状态更新：B-待合并

# A 写了 BRANCH_NOTES.md，完成了阶段①②③
cd /d/xgq/work/skills-ai-feat-a
# 写笔记 → commit
# 状态更新：A-开发中（阶段④）

Day 2 上午：合入 B

cd /d/xgq/work/skills-ai
git merge feat/ai-collaboration-safety --ff-only && git push
# 状态更新：B-已归档

Day 2 全天：专注 A

cd /d/xgq/work/skills-ai-feat-a
# 用 backend-change-flow 完成阶段④⑤⑥⑦
# 状态更新：A-待合并

Day 3 上午：合入 A，创建 reconcile 分支刷新 README

cd /d/xgq/work/skills-ai
git merge feat/backend-change-flow-upgrade --ff-only && git push

git checkout -b chore/reconcile-readme
# 统一改 README 统计数字
# 提 PR → 自审 → 合并

---

🆚 与现有 Skill 的关系

Skill	关系	如何使用
backend-change-flow	每个 feature 的执行器	在每个 worktree 里独立跑七阶段闭环
ai-collaboration-safety	情绪保险	当某个 feature 被 AI 逼疯时，切换到这里恢复
create-pr	合并前检查	每个 feature 合入 main 前，生成规范 PR 描述（即使自己合）
quality-gate	合并前检查	每个 feature 分支提交前跑五维检查
multi-agent-orchestration	进阶并行	如果 feature 完全独立，可用多个 Agent 并行工作（worktree 隔离）
git-commit	规范提交	每个 commit 用 Conventional Commits 格式

最佳实践链：

solo-parallel-dev（分支规划 + worktree 隔离）
     ↓
backend-change-flow（每个 feature 的开发闭环）
     ↓
ai-collaboration-safety（被 AI 逼疯时恢复）
     ↓
quality-gate（提交前检查）
     ↓
create-pr（生成 PR，留记录）
     ↓
solo-parallel-dev（合并 + 归档 + 清理）

---

🚀 快速入口

"我要同时开发几个功能" → 分支规划 + worktree 设置
"分支管理" → 分支状态看板 + 命名规范
"切来切去忘了进度" → 上下文恢复协议
"README冲突" → 冲突预防策略（公共文件延迟修改）
"一个人怎么并行开发" → 完整工作流 + 防烂尾机制

---

"一个人并行开发的关键不是技术——是自律。worktree 帮你物理隔离，看板帮你对抗遗忘，延迟修改 README 帮你避免自己打自己。"