feature分支必须从develop创建，命名严格为feature/xxx格式，测试闭环需ci流水线+真实环境验证，合并后立即删除远程分支，生命周期终结需满足无共同祖先、不被tag/release引用且构建产物过期。
feature 分支必须从 develop 创建，不能从 master 或其他分支硬切
直接从 master 切 feature 分支，会导致新功能缺少已合入 develop 但尚未发布的改动（比如正在测试的接口调整、中间件升级），上线前才发现兼容性问题。更隐蔽的风险是：后续合并回 develop 时，Git 可能因缺失共同祖先而产生大量非必要冲突。
实操建议：
- 始终执行
git checkout develop && git pull origin develop后再创建分支 - 分支命名严格用
feature/xxx格式，避免feat/、feature_xxx等变体（CI/CD 脚本常按正则匹配） - 如果团队使用
dev-1.2.0这类版本化开发分支而非统一develop，则必须明确该版本分支当前是否已同步最新develop提交，否则仍等效于“从旧基线切出”
测试闭环不是指“本地跑通”，而是 PR 中触发完整 CI 流水线 + 人工验证环境部署
很多团队把 feature 分支推送到远程就认为“进入测试”，其实只是起点。真正的闭环要求：代码通过所有自动化检查（单元测试覆盖率 ≥80%、ESLint 零警告、构建成功），且生成的镜像或包被部署到与生产环境配置一致的 test 环境，并由测试人员在真实 URL 上完成核心路径验证。
常见断点：
- CI 脚本未配置
feature/*分支的构建触发规则，导致推送后无任何反馈 -
test环境数据库未隔离，多个feature分支共用同一套测试数据，相互污染 - 前端静态资源未带分支标识，不同
feature部署后浏览器缓存混淆，误判功能表现
合并后必须立即删除远程 feature 分支，本地可保留但禁止复用
不删远程分支不仅造成仓库杂乱，更关键的是：它会持续接收无关提交（比如误操作 git push origin feature/login）、干扰分支保护规则（某些平台对未删除分支仍开放直接推送权限）、并在下次基于同名分支创建时引发 Git 历史错乱（尤其当原分支曾被 force-push 过）。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
正确动作链：
- PR 合并成功后，平台自动删除远程分支（需在 GitHub/GitLab 设置中开启 “Delete head branch”）
- 本地执行
git branch -d feature/login（注意是小写-d，非-D；若提示未完全合并，说明还有未 merge 的提交，必须查清） - 绝对不要用
git checkout feature/login && git pull继续开发——这是典型“复用已终结分支”，应新建feature/login-v2或直接基于develop拉新分支
生命周期终结的隐性标志：分支最后一次 commit 不再被任何 tag 或 release 分支引用
即使 PR 已合并、远程分支已删，只要该分支的某个 commit 还出现在 release/1.5.0 或 v1.5.0 tag 的历史中，它就仍在发布链上承担事实责任。此时若发现该 commit 引发线上问题，修复仍需追溯到原始 feature 分支上下文。
所以真正终结的判断依据是：
-
git merge-base feature/login release/1.5.0返回空（说明无共同祖先） -
git tag --contains <feature-commit-hash></feature-commit-hash>无输出 - CI 日志中该分支最后构建产物已过期（如超过 90 天未被拉取）
这个层面的终结无法靠命令一键完成，依赖团队对发布节奏和归档策略的共识。
