git分支策略直接决定ci流水线触发时机：github flow要求pr事件触发，gitflow需为develop/release分支独立配置，tbd则仅对main配置push触发且须启用提交前门禁；错误策略会导致测试漏跑、误部署或pr卡死。
Git分支策略如何影响CI流水线触发时机
CI流水线不是自动感知“代码变了”就跑，而是依赖分支事件（如 push、pull_request）被明确配置后才触发。选错策略会导致测试漏跑、环境误部署或PR卡死。
常见错误现象：main 分支没保护，开发者直接 git push 上去，CI还没来得及验证就进了生产；或者 feature/* 分支没配 push 触发，本地测完一推远程，发现单元测试根本没跑。
-
GitHub Flow要求所有功能必须走pull_request事件触发CI：PR创建、更新、合并前都应运行完整测试套件 -
GitFlow中develop和release/*分支需独立配置：前者用于每日构建+集成测试，后者需额外加冒烟测试和版本签名 - 若用
Trunk-Based Development (TBD)，则只对main配置push触发，且必须启用“提交前门禁”（pre-commit gate），否则小修改可能绕过CI
为什么 feature 分支不能长期存在——CI视角下的腐化风险
从CI角度看，长期不合并的 feature 分支本质是“离线开发”，它脱离了主干的测试反馈循环，越拖越难合。不是代码写得不好，是它已经和 main 的依赖、接口、测试断层了。
典型表现：git merge main 后 CI 突然大量失败，但本地 git pull && npm test 是绿的——因为本地没跑全量集成测试，也没连真实数据库或服务 mock。
- 建议硬性规则：所有
feature/*分支存活期 ≤ 3 天，超时自动标记为 stale，CI 加告警 - 每天至少一次
git rebase main或git merge main，并确保 CI 在该操作后重新运行 - 避免在
feature分支上跳过 CI（如[skip ci]），尤其不能跳过 lint 和单元测试
merge 与 rebase 在 CI 流程中的实际取舍
CI 不关心你用什么命令合并，但它极度依赖提交历史是否可追溯、可重放。rebase 后的线性历史让 git bisect 定位问题快得多；但乱用 rebase 会破坏 PR 的审查上下文，导致 CI 报告和代码评审脱节。
错误做法：在已推送的 feature 分支上反复 git push --force-with-lease，导致 CI 重跑时拉不到旧 commit，缓存失效、覆盖率统计错乱。
- 推荐组合：
rebase仅用于本地整理提交（比如把 “fix typo” 合进前一个 commit），合并前再git push --force-with-lease一次 - PR 合并方式统一设为
rebase and merge（GitHub）或Squash and merge（GitLab），确保main历史干净且每条提交对应一个完整功能 - 禁用
fast-forward merge：它会让 PR 的 diff 消失，CI 无法关联到原始审查记录
CI失败时，分支策略决定回滚成本
CI 失败本身不致命，致命的是你有没有清晰的“可回退锚点”。GitFlow 的 release/* 分支天然提供这个锚点；而 GitHub Flow 下，如果没打 v1.2.3 tag 就合并，失败后只能靠 git revert，容易漏改或冲突。
最容易被忽略的一点：CI 流水线里跑的构建产物（如 Docker 镜像、npm 包）必须绑定到不可变的 commit hash，而不是分支名。否则 main 分支被 force push 后，线上部署的镜像 ID 可能指向完全不同的代码。
- 每次成功 CI 构建后，自动生成并推送带 commit hash 的语义化 tag（如
v1.2.3+gabc123） - 发布流程必须从 tag 拉取，而非分支；
hotfix也应基于 tag 创建，而不是main当前 HEAD - CI 配置中禁止使用
origin/main这类动态引用，全部替换为${GITHUB_SHA}或等效变量
