NocoBase 近期更新继续围绕功能优化与缺陷修复展开。比单条修复内容更值得运维团队关注的是，它同时维护 main、next 和 develop 三个分支，分别服务于生产部署、提前验证和开发协作。选错分支，可能把尚未充分验证的变化带进生产环境；建立清晰的升级通道，则能把每周更新变成可控的工程流程。
需要说明的是，本次摘要没有列出具体修复项，因此不宜推断某个插件、接口或 AI 功能已经解决了特定问题。实际升级前，仍应结合完整更新日志和自己的回归测试判断影响范围。
三个分支不是版本高低，而是风险等级
main 是当前最稳定的分支，也是官方推荐安装的版本。生产环境、新项目默认安装以及缺少专门测试资源的团队，都应优先使用它。
next 包含即将发布的新功能，并已完成初步测试，但仍可能存在已知或未知问题。它更适合作为预发布环境的来源：团队可以提前检查表单、权限、工作流、插件和数据模型是否受到影响，同时向项目反馈问题。
develop 则应视为开发协作分支。虽然摘要没有进一步描述其稳定性承诺，但从三分支模型看，可以这样实践：仅在研发沙箱或自动化集成环境中使用，不直接承载生产数据，也不作为业务人员的日常工作入口。
| 分支 | 推荐环境 | 主要目的 | 风险控制 |
|---|---|---|---|
main |
生产环境 | 稳定运行 | 备份后升级并执行回归测试 |
next |
预发布环境 | 提前验证新功能 | 使用脱敏数据，允许快速回滚 |
develop |
研发沙箱 | 开发与集成验证 | 隔离部署，不连接生产数据库 |
把更新检查变成可重复的操作
不要只执行一次 git pull 就开始升级。更稳妥的做法是先记录当前提交，再获取远端状态，并查看目标分支带来了哪些提交。下面的脚本适用于已经通过 Git 克隆的 NocoBase 项目；运行前把第一个参数改为本地仓库目录，第二个参数设为允许的目标分支。
#!/usr/bin/env bash
set -euo pipefail
REPO_DIR="${1:-.}"
TARGET_BRANCH="${2:-main}"
case "$TARGET_BRANCH" in
main|next|develop) ;;
*)
echo "Unsupported branch: $TARGET_BRANCH" >&2
exit 1
;;
esac
cd "$REPO_DIR"
git fetch --prune origin
CURRENT_BRANCH="$(git branch --show-current)"
CURRENT_COMMIT="$(git rev-parse HEAD)"
TARGET_COMMIT="$(git rev-parse "origin/${TARGET_BRANCH}")"
echo "Current branch: $CURRENT_BRANCH"
echo "Current commit: $CURRENT_COMMIT"
echo "Target branch: $TARGET_BRANCH"
echo "Target commit: $TARGET_COMMIT"
echo
echo "Commits pending deployment:"
git log --oneline --no-decorate "HEAD..origin/${TARGET_BRANCH}" || true
echo
echo "Changed files:"
git diff --name-status "HEAD...origin/${TARGET_BRANCH}" || true
例如，将脚本保存为 inspect-nocobase-update.sh 后执行：
chmod +x inspect-nocobase-update.sh
./inspect-nocobase-update.sh /srv/nocobase main
这个脚本只检查差异，不会切换分支或修改工作区，适合放在正式升级之前。检查结果中如果出现数据库迁移、权限、认证、工作流或插件相关文件，应扩大回归范围，而不是直接推进发布。
建立 main、next、develop 的晋级路径
三分支并行的价值，不只是让用户自行选择版本，还可以形成一条内部验证链路：
develop -> 研发沙箱 -> 技术验证
next -> 预发布环境 -> 业务回归
main -> 生产环境 -> 受控发布
可以这样实践：预发布环境持续跟踪 next，但生产环境始终固定在 main 的某个已验证提交，而不是无条件跟随分支最新状态。验证完成后记录精确的 Git 提交哈希，部署时使用同一提交，从而避免测试结束到生产发布之间又混入新的变更。
一份最小发布记录可以采用以下 YAML。它不是 NocoBase 官方配置，而是可纳入团队发布仓库的审计模板：
application: nocobase
release_channel: main
commit: "REPLACE_WITH_VERIFIED_COMMIT_SHA"
environments:
staging:
source_branch: next
database: sanitized-copy
production:
source_branch: main
database_backup_required: true
checks:
- login-and-session
- role-permissions
- form-create-update-delete
- workflow-trigger
- installed-plugins
rollback:
application_revision_required: true
database_restore_tested: true
其中 commit 必须替换为测试通过的真实提交哈希。若升级包含数据库结构变化，仅回退应用代码可能不够，因此还要确认数据库迁移是否支持逆向操作，并提前验证备份恢复。
升级时真正要检查什么
无代码平台的变化往往会沿着配置和数据扩散。页面能够打开，并不代表升级已经验证完成。建议至少覆盖以下场景：
- 管理员和普通角色能否正常登录，菜单与数据权限是否符合预期。
- 核心数据表能否完成新增、查询、编辑和删除操作。
- 自动化工作流、定时任务和外部通知能否按预期触发。
- 已安装插件是否兼容目标版本，尤其是内部开发或第三方插件。
- API 集成、Webhook 和单点登录是否仍保持原有契约。
- 升级前备份是否可恢复，应用版本与数据库状态能否一起回退。
对大多数团队，合理的默认策略很直接：生产使用 main，预发布使用 next，develop 只进入隔离的研发环境。想提前体验功能时，不必用生产稳定性换取速度；把新版本放入预发布环境，用真实流程和脱敏数据完成验证，再决定何时升级。