分支

你可以在任何方案下直接从 GitHub 部署 —— 连接你的仓库，推送到 main 的更改会自动部署到你的项目。分支功能更进一步，为每个拉取请求添加独立的预览环境。

🌐 You can deploy directly from GitHub on any plan — connect your repository and changes pushed to main are automatically deployed to your project. Branching takes this further, adding isolated preview environments for each pull request.

使用分支来安全地尝试对你的 Supabase 项目进行更改。

🌐 Use branching to safely experiment with changes to your Supabase project.

Supabase 分支可以创建从你的主项目分离出来的独立环境。你可以用这些分支环境来创建和测试比如新配置、数据库模式或功能的更改，而不会影响你的生产配置。当你准备好发布更改时，只需合并你的分支，就能用新的更改更新你的生产实例。

🌐 Supabase branches create separate environments that spin off from your main project. You can use these branching environments to create and test changes like new configurations, database schemas, or features without affecting your production setup. When you're ready to ship your changes, merge your branch to update your production instance with the new changes.

分支是怎么运作的 #

🌐 How branching works

• 独立环境：每个分支都是一个独立环境，拥有自己的 Supabase 实例和 API 凭证。
• 预览分支：预览分支是短暂的，最适合进行专注的测试。它们在不活跃时会自动暂停，或者在 PR 被合并或关闭时被删除。
• 持久分支：持久分支是存在时间较长的分支，推荐用于预发布、质量检测或开发环境。不同于预览分支，它们不会因为不活跃或PR被合并/关闭而自动暂停或删除。
• 管理分支：你可以通过我们的 GitHub 集成 自动创建、查看和合并分支，或者直接 通过仪表板（目前处于测试版）操作。所有分支都会显示在仪表板的分支页面上，无论它们是如何创建的。
• 无数据：新分支不会从你的主项目中获取任何数据。这是为了更好地保护你的敏感生产数据。如果你想让分支拥有数据，可以在使用 GitHub 集成时使用种子文件启动分支。

部署到生产环境 #

🌐 Deploying to production

当你将任何分支合并到主项目时，Supabase 会自动运行一个部署工作流，将你的更改部署到生产环境。这个部署工作流表现为一个有向无环图，其中每个节点代表以下某个部署步骤。

🌐 When you merge any branch into your main project, Supabase automatically runs a deployment workflow to deploy your changes to production. The deployment workflow is expressed as a Directed Acyclic Graph where each node represents one of the following deployment steps.

1. 克隆 - 在指定的 git 分支上检出你的仓库（可选，用于通过仪表板分支）
2. 拉取 - 从你的主项目中获取数据库迁移（在通过仪表板分支时，也会初始化迁移历史表）
3. 健康 - 等待最多 2 分钟，直到你分支上的所有 Supabase 服务（包括认证、API、数据库、存储和实时）都在运行且状态良好
4. 配置 - 根据你的 config.toml 文件更新服务配置（仅适用于 通过 GitHub 分支）
5. 迁移 - 将待处理的数据库迁移和保险库秘密应用到你的分支
6. Seed - 运行种子文件以为你的分支填充初始数据（必须在 config.toml 中启用才能对持久分支生效）
7. 部署 - 部署任何已更改的 Edge 函数并更新函数密钥

如果父部署步骤失败，所有依赖的子步骤都会被跳过。例如，如果你的数据库迁移在第5步失败，我们的运行器就不会对你的分支进行数据填充，因为第6步会被跳过。如果你使用 GitHub 集成，同样的部署工作流会在每次推送到你的 git 分支时运行。

🌐 If a parent deployment step fails, all dependent child steps will be skipped. For instance, if your database migrations failed at step 5, our runner will not seed your branch because step 6 is skipped. If you are using GitHub integration, the same deployment workflow will be run on every commit pushed to your git branch.