31 lines
1.5 KiB
Markdown
31 lines
1.5 KiB
Markdown
# 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），无需推翻现有模型。
|