分支策略用于隔离不同阶段的代码和配置变更。New IDE 中，团队可以通过 Git 分支管理开发、测试和生产配置，再结合 Project、项目参数、资源绑定和发布流程控制不同环境的运行行为。
分支策略不是唯一标准。团队可以根据规模、发布频率和治理要求选择轻量或严格的方式。关键原则是：生产发布来源应清晰、可追踪、可审查。

常见分支模型 #

较小团队也可以采用简化模型，例如 feature/* -> main，但仍建议通过 Pull Request、Diff 或发布复查确认生产变更。

分支与环境的关系 #

Git 分支可以承载不同阶段的代码和配置，但环境差异不应全部写死在分支中。建议将环境差异拆成三类管理：

例如，dev 和 prod 可以使用同一份 Pipeline 配置结构，但通过不同项目参数指定数据库名、对象存储路径、资源组或环境标识。

推荐发布路径 #

一个常见路径如下：

feature/order-quality-check
  -> develop
  -> staging
  -> main
  -> New IDE 发布为 Online Pipeline

每一阶段建议完成不同检查：

参数和资源隔离 #

避免在代码中硬编码环境信息。建议使用参数或资源配置表达差异。

这样可以减少分支之间的重复配置，也能降低误把开发环境路径发布到生产的风险。

分支命名建议 #

分支名称应能表达业务意图，避免只有个人姓名或无意义编号。

发布前检查 #

从生产分支发起发布前，建议确认：

• 当前 Git Folder 位于预期分支。
• 本次变更已经完成审查。
• Pipeline 配置校验通过。
• 发布 Diff 中的 Activity、依赖、参数、资源、Run As 和调度配置符合预期。
• 项目参数和资源绑定指向正确环境。
• 没有提交明文 Token、密码或敏感连接信息。
• 责任人和告警接收范围符合生产要求。

紧急修复建议 #

生产故障需要紧急修复时，可以使用 hotfix/* 分支。修复后建议：

• 从生产分支创建 hotfix 分支。
• 只修改本次故障必要内容。
• 完成配置校验和必要运行验证。
• 合并回生产分支并发布。
• 同步回开发或集成分支，避免之后的版本覆盖修复。

常见风险 #