1. 产品介绍
给应用准备一个可以读写的后端
Supabase围绕 Postgres 关系数据库提供应用后端能力：保存业务数据、通过 API 访问，并与登录、文件存储和函数等服务配合。它适合开发预约、内容或业务管理应用，不是只供人查看报表的工具。
假设你维护一家摄影工作室的预约网站，准备给订单增加“拍摄时长”。直接修改线上数据库，会让正在使用旧表单的人面对尚未验证的新规则。本文聚焦的分支功能，把这次结构尝试放进另一个环境，再决定怎样带回正式项目。
这里的结构是表、列、约束等规则，数据是已经存在的预约记录。复制了结构，不代表同时复制了客户预约。
2. 核心使用流程
先获得正确入口，再创建隔离环境
以给摄影预约增加“拍摄时长”为教学情境，先区分结构与数据：列、约束是结构，已有预约是数据。仪表盘指南说明，新项目首次使用不连接 GitHub 的分支时，需要 Owner 或 Administrator 启用；之后 Developer 角色也可创建、更新和删除预览分支。
从分支选择器创建分支，确认当前编辑目标。分支概览说明分支有独立实例和凭据，默认不带生产数据与存储对象。需要 Include data 时依赖 PITR（按时间点恢复数据库）附加功能并增加资源成本；只验证字段规则时，可以先准备受控测试记录。
在分支里把结构与应用一起试过
- 连接测试应用：使用分支自己的连接信息和 API 访问密钥，避免画面看似在测试、请求却仍发向生产。
- 修改结构：通过 SQL Editor 或 Table Editor 增加时长字段，确定空值、默认值与约束。
- 放入有意义的数据：不仅测试一条完整新预约，也检查缺少时长的旧记录怎样经过变化。
- 验证新旧客户端：新表单能写入还不够，旧表单的提交和读取也要有明确预期。这些是迁移验收建议，分支不会自动替团队覆盖全部业务条件。
独立环境让试改有落点，但“空库里建表成功”与“旧业务能够迁移”仍是两个不同结论。
先审阅迁移，再决定怎样带回正式项目
无需 Git 的分支路径把创建、编辑、生成差异与合并连起来。迁移是把数据库结构从旧状态改到新状态的一组操作。创建合并请求后阅读结构变化，有冲突先处理，再确认应用到正式环境。合并传递的是结构迁移，不是把预览环境的一切整体覆盖到线上。
生成差异的 pg-delta 仍标为 alpha（早期试验阶段），自动结果应作为审阅材料。新增必填字段、删除约束和修改默认值分别有什么后果，需要结合旧记录与旧代码判断。完成这条流程，意味着已经在分支里试过改动，并清楚知道哪些结构变化将应用到正式项目，而不只是成功点过合并。
3. 设计亮点与借鉴
把“在哪个环境修改”做成持续可见的上下文
仪表盘的分支选择器决定 SQL 与表格编辑面向哪个环境；外部程序则使用该分支自己的连接信息。对摄影工作室来说，“给预约加一列”看起来是相同操作，但在预览与生产环境执行的后果完全不同。
这个设计值得关注的地方，是环境不只是创建时选过一次的配置，而是每次编辑都应能确认的上下文。独立凭据使应用连接也跟随环境区分。团队还需要在自己的测试应用里显露环境名称，避免把一张看起来正常的页面误认成预览结果。
把一次直接修改，变成可审阅的迁移
在表格编辑器里编辑表结构、增加字段很直观，但团队真正需要确认的是“会改变什么”。差异预览把交互动作转成了可讨论的结构变化：新增列、删除约束、修改默认值，影响并不相同。
因此，确认前最有价值的问题不是“界面是否保存成功”，而是“旧记录与旧代码怎样经过这次变化”。先展示变化，再要求确认，给开发者留下了发现误删和缺少迁移步骤的机会。
让试验入口适应已有工作方式
不要求先建立 Git 集成，就能开始一次分支试改，降低了使用仪表盘管理结构的人采用隔离环境的门槛。已经把迁移放在代码审查里的团队，则可以继续使用 Git 路径。
这体现了一种值得借鉴的取舍：让人更容易先在分支里试改，再看清变化，最后确认是否应用到正式项目。方便应让人更容易进入正确环境、看见变化，而不是让确认消失。