# ADR 0005：分支策略（简化版 GitFlow）

- **状态**：已接受
- **日期**：2026-09-04

## 背景

项目进入多模块骨架建设阶段，单人/小团队开发。需要明确一套分支流，既保证 `main` 始终可发布，又不引入超过当前规模的开销。当前 `dev` 与 `main` 处于同一 commit（尚未分叉），正是定策略的时机。

## 决策

采用**简化版 GitFlow**：

- `feature/<name>` 从 `dev` 拉取，完成后 **merge 回 `dev`**（不直接进 `main`）。
- `dev` 作为集成点，保持可构建；所有 feature 先合入这里。
- `dev` 稳定后，**经人工确认**再 merge 回 `main`。
- 当前阶段**不引入 `release/*`**；`hotfix/<name>`（从 `main` 拉，合回 `main` + `dev`）按需使用。

日常操作细节见 [docs/gitflow.md](../gitflow.md)。

## 理由

- 严格 GitFlow 中，`main` 只经 `release/*` / `hotfix/*` 进入，feature 永不直接碰 `main`。在基础建设阶段，`release/*` 分支是纯负担。
- 简化版保留了两个关键性质：**`dev` 是集成点**（隔离未稳定代码）、**`main` 只放可发布状态**，同时免去 release 分支的管理开销。
- 与 `feature/<name>/` 模块目录名对齐的命名，让分支与代码结构一一对应。

## 后果

- `main` 始终为可发布状态；进入 `main` 的合并必须人工确认。
- 未来团队扩大或进入正式发布周期，可平滑升级为完整 GitFlow（引入 `release/*`、正式版本 tag），无需推翻现有模型。