调整分支策略: 仅 master 部署, 取消 dev-* 自动发布

分支规则 (写入 readme):
- master   主分支, 唯一部署出口, push 即发布生产
- dev-*    开发集成分支, 只跑 CI 校验, 不部署; 上线先合到 master
- tmp-*    临时分支, 针对单个问题, 合到 dev-* 后删除
- android-* 仅触发 APK 外壳构建, 构建前须与 master 同步

CI 变更:
- .gitea/workflows/docker-build.yml 触发分支收窄为 master
  此前 dev-* 与 master 共用同一套生产环境, 推送开发分支即直接发布,
  容易把半成品带上线, 现取消该触发
- 同步修正工作流内相关注释 (迁移时机, 版本校验范围)

文档变更:
- readme 新增「分支规则」章节: 职责表/流程图/CI 触发范围/变更说明
- readme 原「分支与 CI/CD」章节与新规则冲突, 已按新策略重写
  (dev-* 不再触发部署; 数据库迁移只在 master 发布时应用)
- 明确团队约定的 main 主分支在本仓库落地为 master

.gitea/workflows/docker-build.yml

@@ -1,17 +1,22 @@
 name: Docker Build and Push
 
-# main / master / dev-* 分支 push 触发, 其他分支不触发
+# 仅主分支 (master) push 触发部署; 其他分支一律不触发 (见 readme「分支规则」)
 # 每次提交: 构建前端 + 生成 OTA 升级包 (签名) → 打进 Docker 镜像 → 自动升级数据库 → 部署
 # OTA 随镜像发布: 容器内 OTA_PACKAGE_DIR=/app/ota-package 指向打包的 ota-package/
 #
-# dev-* (如 dev-0.1 / dev-0.2) 与 main/master 部署到同一套环境 (容器 iboard, 宿主 3001),
-# 即开发分支推送 = 直接发布: 数据库共用同一个库, migrate deploy 在启新容器前执行 (幂等).
+# 分支策略 (2026-10 调整):
+#   - master  = 主分支, 唯一部署出口, push 即发布生产 (容器 iboard, 宿主 3001)
+#   - dev-*   = 开发集成分支, 只做 CI 校验 (构建/版本一致性), **不再自动部署**;
+#               要上线必须先合并到 master 再推 master
+#   - tmp-*   = 单个问题的临时分支, 合到 dev-* 后删除
+#   - android-*= 只用于触发 APK 外壳构建, 不部署; 改动前须与 master 同步
+#
+# 历史: 之前 dev-* 与 master 共用同一套生产环境 (推送即发布), 容易把半成品带上线,
+#       现已取消 dev-* 的 push 触发。
 on:
   push:
     branches:
-      - main
       - master
-      - 'dev-*'
 
 jobs:
   build-image:
@@ -39,6 +44,7 @@ jobs:
         #    （tauri.conf.json 的 version 就是 APK 的 versionName）
         # 2) 防止 OTA 版本号与分支错位: OTA 包的 version 直接取自 package.json,
         #    dev-0.2 分支上必须是 0.2.x, 否则线上 OTA 会报成上一个版本的号
+        #    (master 分支跳过分支前缀校验, 但四处一致性照样强制)
         env:
           GITHUB_REF_NAME: ${{ github.ref_name }}
         run: node scripts/ci/check-version.mjs
@@ -75,7 +81,7 @@ jobs:
         run: docker images
 
       - name: Apply DB migrations
-        # 数据库自动升级: 按 prisma/migrations/ 下的迁移顺序应用 (dev-* 与 main/master 共库)
+        # 数据库自动升级: 按 prisma/migrations/ 下的迁移顺序应用 (生产库由 master 部署时统一升级)
         # migrate deploy 幂等, 无新迁移时为 no-op
         # 位置关键: 在 "Remove old container" 之前 —— 建表/改表成功后才切换流量,
         # 迁移失败则整个 workflow 中断, 不会用新镜像顶掉仍在运行的旧容器

readme

@@ -1,6 +1,50 @@
 # iBoard
 用于收集和整理经济数据，但是以策略为主体重新组织。
 
+## 分支规则
+
+### 分支类型与职责
+
+| 分支 | 职责 | 部署 | 合并方向 |
+| --- | --- | --- | --- |
+| `master` | **主分支**（生产分支） | ✅ 唯一部署出口，push 即发布生产 | — |
+| `dev-*` | **开发集成分支**，如 `dev-0.2` | ❌ 不部署（只跑 CI 校验） | 合到 `master` 后由 master 部署 |
+| `tmp-*` | **临时分支**，针对单个问题的修改 | ❌ 不部署 | 合到对应 `dev-*` 后删除 |
+| `android-*` | **Android 外壳构建分支**，如 `android-1.0` | ❌ 不部署，只触发 APK 构建 | 构建前须与 `master` 同步 |
+
+> **关于 `main`**：团队约定里的「main 主分支」在本仓库落地为 **`master`**（仓库默认分支即 `master`，不另建 `main`）。
+> 下文所有「main 主分支」均指 `master`。
+
+### 流程
+
+```
+tmp-xxx  ──合并──▶  dev-0.2  ──合并──▶  master  ──push──▶  自动部署生产
+   │                    │
+   │                    └──push──▶ 只跑 CI（版本一致性校验），不部署
+   │
+   └── 问题解决后删除
+
+android-1.0 ── 从 master 同步代码后 push ──▶ 只触发 APK 构建 / 发布到 Packages
+```
+
+1. **日常开发**：从 `dev-*` 拉 `tmp-*`，改完合回 `dev-*`，`tmp-*` 用完即删。
+2. **上线**：`dev-*` 验收通过后合并到 `master`，**推送 `master` 才部署生产**。
+3. **打 Android 包**：`android-*` 与 `master` 同步（`git merge master` 或 `git reset --hard origin/master`）后推送，
+   触发 [android-build.yml](.gitea/workflows/android-build.yml)，产物发布到 Gitea Generic Packages。
+
+### CI 触发范围
+
+| 工作流 | 触发分支 | 动作 |
+| --- | --- | --- |
+| [docker-build.yml](.gitea/workflows/docker-build.yml) | **仅 `master`** | 构建前端 + 生成签名 OTA 包 + 构建镜像 + 迁移数据库 + 部署生产 |
+| [android-build.yml](.gitea/workflows/android-build.yml) | `android-*` | 构建并签名 release APK，上传到 Packages |
+| [ota-build.yml](.gitea/workflows/ota-build.yml) | 仅手动 `workflow_dispatch` | 单独构建/签发 OTA 包 |
+| [sync-registry.yml](.gitea/workflows/sync-registry.yml) | 见文件 | 同步注册中心 |
+
+> ⚠️ **重要变更（2026-10）**：`dev-*` 分支**已取消** push 自动部署。
+> 此前 `dev-*` 与 `master` 共用同一套生产环境，推送开发分支等于直接发布，容易把半成品带上线。
+> 现在开发分支的提交只有合并进 `master` 并推送后才会部署。
+
 ## 版本管理
 
 ### 一句话规则
@@ -60,19 +104,21 @@ tauri.android.versionCode = 2000      # 整数，升级判定用 = major*1000000
 ## 分支与 CI/CD (Gitea Actions)
 
 分支按版本命名：`dev-0.1`、`dev-0.2`…… 对应 `docs/V<版本>/` 下的需求/设计文档。
+职责与合并方向见上文「分支规则」。
 
 | 分支 | 触发的 workflow | 行为 |
 | --- | --- | --- |
-| `main` / `master` | `docker-build.yml` | 生产发布：构建前端 → 生成签名 OTA 包 → 打 Docker 镜像 → 数据库自动升级 → 重启容器 `iboard` (宿主 3001) |
-| `dev-*` | `docker-build.yml` | **与生产同环境**：推送即构建、迁移数据库、部署（开发分支直接顶掉生产，含 OTA 热更） |
-| `android-*` | `android-build.yml` | 打签名 release APK 并上传到 Gitea Generic Package Registry |
+| `master`（主分支） | `docker-build.yml` | 生产发布：构建前端 → 生成签名 OTA 包 → 打 Docker 镜像 → 数据库自动升级 → 重启容器 `iboard` (宿主 3001) |
+| `dev-*` | **不触发部署** | 推送只走版本一致性校验；上线须先合并到 `master` |
+| `tmp-*` | 不触发 | 临时分支，合到 `dev-*` 后删除 |
+| `android-*` | `android-build.yml` | 打签名 release APK 并上传到 Gitea Generic Package Registry（构建前须与 `master` 同步） |
 | 手动 | `ota-build.yml` / `sync-registry.yml` | 单独出 OTA 包 / 同步 secrets 到注册中心 |
 
 数据库升级约定：
 - 唯一入口是 `prisma/migrations/` 下的迁移文件，由 `npx prisma migrate deploy` 在**启新容器之前**执行
   （幂等，无新迁移时为 no-op）；迁移失败会中断 workflow，不会用新镜像顶掉仍在运行的旧容器。
-- `dev-*` 与 `main/master` 共用同一个 MariaDB 库（同一个 `DATABASE_URL` secret），
-  因此开发分支上的迁移会直接作用到该库结构，合入前请确认迁移可回滚。
+- 由于只有 `master` 会部署，**迁移真正作用到生产库的唯一时机就是 master 发布**；
+  开发分支上的迁移不会被自动应用，请在合并到 `master` 前确认可回滚。
 - 本地改了 `prisma/schema.prisma` 后：写迁移 SQL → `npx prisma migrate deploy` 验证 → 提交迁移目录。
 
 - 首页主要是放经济文章