不能直接在main上开发新功能，因为main对应线上稳定版本，直接提交会导致测试、灰度、回滚链条断裂；常见后果包括测试环境运行未完成逻辑、合并冲突掩盖语义冲突；团队超1人或有并行需求时必须用分支隔离。

为什么不能直接在 main 上开发新功能

main 分支通常对应线上稳定版本，直接提交新功能代码会导致测试、灰度、回滚链条断裂。最常见后果是：测试环境跑着带未完成逻辑的代码，发布时才发现 git merge 冲突掩盖了语义冲突（比如两个分支都改了同一段权限校验，但逻辑相反）。

关键判断：只要团队超过 1 人、或存在并行需求（如 A 开发支付模块、B 准备下周一发布运营活动），就必须用分支隔离。

推荐的三分支模型及其职责

不是所有分支策略都适合中小团队。实操中验证下来，main + develop + feature/* 组合最易落地，且与 CI/CD 工具链兼容性好。

• main：只接受来自 release/* 或 hotfix 分支的合并，每次合并即触发生产部署；标签（tag）必须打在 main 提交上
• develop：集成所有已完成的 feature/* 分支，每日构建测试环境；禁止直接提交
• feature/login-v2 这类命名：功能开发全在该分支进行，完成后发起 PR 合入 develop，不直连 main

注意：release/1.2.0 分支只在准备发布时从 develop 切出，修复发布前 bug，验证通过后同时合入 main 和 develop ——漏掉后者会导致下个迭代丢失本次修复。

GitHub Actions Retry Recovery Audit

审计 GitHub Actions 运行，检测失败后成功的重试恢复模式，量化 flaky 重运行的浪费。

下载

如何避免 feature 分支长期未合入导致的“合并地狱”

核心矛盾不是 Git 能力问题，而是协作节奏问题。一个 feature/user-profile 分支存活超 2 周，大概率会遇到：接口字段变更未同步、mock 数据结构过期、CI 流水线脚本升级后失效。

• 强制要求：每个 feature/* 分支每天至少执行一次 git rebase develop（非 merge），保持与集成分支线性一致
• CI 必须配置 pre-merge 检查：在 PR 创建/更新时，自动将目标分支（develop）最新提交临时合入当前 PR 分支再跑测试
• 开发者本地需设置 git config --global pull.rebase true，否则 git pull 默认产生无意义合并提交，污染历史

示例：若 feature/order-refund 的 PR 显示 “Conflicts: api/order.go”，不要手动解决后强行 push —— 先 git fetch origin && git rebase origin/develop，再检查业务逻辑是否仍正确。

测试环境和发布流程怎么绑定分支

自动化程度决定分支策略成败。没有环境自动映射，分支就只是文件夹名字。

• 测试环境（test.example.com）只部署 develop 分支最新成功构建；每个 feature/* 分支可单独触发临时环境（如 feature-login-v2.test.example.com），但需明确生命周期（默认 72 小时自动销毁）
• 预发布环境（staging.example.com）严格对应 release/* 分支构建，且必须通过完整回归测试集才允许合入 main
• 生产发布必须由 main 分支 tag 触发（如 v1.2.0），禁止用分支名或 commit hash 部署 —— tag 不可篡改，是审计唯一依据

容易被忽略的一点：所有环境的数据库连接配置、密钥注入方式必须通过分支名动态区分，而不是靠人工修改 config 文件。否则 feature/* 环境误连生产库的事故，三年内至少发生过两次。