main分支必须始终可部署，这是github flow有效运行的前提；一旦其不可部署，后续所有pr将失去可信集成基线，导致ci失效、部署失败或环境割裂等问题。
main 分支必须可随时部署，否则 GitHub Flow 就失效了——这是所有踩坑的起点。
为什么 main 必须始终处于可部署状态
GitHub Flow 的核心不是“分支多不多”，而是“集成是否非阻塞”。一旦 main 出现编译失败、测试挂掉、或环境不兼容，后续所有 PR 就失去可信基线：你无法判断新功能是真通过了集成，还是恰好没触发那个已存在的缺陷。
常见错误现象包括：
- 本地
git push origin main成功，但 CI 没跑（漏配on: [push]或分支名写成master） -
main上存在未修复的 flaky test，导致每次 PR 都要人工点 “re-run” - 部署脚本依赖某个未提交到
main的环境变量，导致自动部署失败但 PR 仍被合并
实操建议：
- 在
.github/workflows/ci.yml中强制监听push到main，且至少包含npm test和npm run build - 禁止任何直接向
main的 force-push 或历史重写；CI 失败时，必须通过新 commit 修复，而非 revert 后再 push - 把部署入口（如
deploy.sh）和配置（如.env.production模板）一并纳入main，避免“代码在 main，配置在别处”的割裂
Pull Request 不只是合并通道，更是集成沙盒
PR 在 GitHub Flow 里不是“等审批完再测”，而是“测过了才该被审批”。它的生命周期必须覆盖从变更提交、CI 验证、预发布环境部署，到人工评审的完整闭环。
容易忽略的关键点：
- CI job 必须使用
pull_request触发器，而不是只靠push；否则 PR 页面看不到检查状态 - 预发布（staging）部署应绑定到 PR 打开事件，且 URL 要能从 PR 描述中一键跳转（例如用
https://pr-${{ github.event.number }}.staging.example.com） - 禁止在 PR 描述里写 “WIP” 或 “DO NOT MERGE” —— 这说明流程卡点了，应该停掉当前分支，先修复 CI 或环境问题
示例片段（.github/workflows/staging.yml）：
on:
pull_request:
types: [opened, synchronize, reopened]
注意：不要加 branches 过滤，PR 的 base 分支默认就是 main，加了反而可能漏掉跨分支 PR（比如临时从 dev 提的）。
合并后立即部署，但不是“无条件部署”
GitHub Flow 要求合并即部署，但这个“部署”必须是幂等、可灰度、可回滚的操作。很多人误以为“自动 merge 就等于自动上线”，结果线上炸了才发现没做流量控制。
关键约束：
- 部署 job 必须由
pull_request_target或workflow_dispatch触发，不能用push到main直接触发——否则恶意 PR 可伪造推送事件 - 生产部署前必须有显式 gate，比如要求至少 1 个 approval + 所有 checks passed +
productionenvironment 的 manual approval - 部署命令本身应带版本标识，例如
fly deploy --image your-app:${{ github.sha }}，避免用:latest导致不可追溯
如果你用的是 GitHub Environments，记得在 environment: production 下配置 protected rules，否则手动审批形同虚设。
特性分支命名和生命周期管理
分支名不是随便起的，它直接影响可读性、自动化识别和清理成本。GitHub Flow 不反对长分支，但反对“不知所云”的分支名。
有效命名规则：
- 以动词开头：
fix-login-timeout、add-api-rate-limit、refactor-payment-service - 避免含糊词：
bugfix、update、new-feature全部不合格 - 长度控制在 30 字符内；过长会在 CLI 和 GitHub UI 中截断，影响排查
分支清理不是“merge 后删”，而是“merge 后自动删”：
- 在 PR 设置里打开
Delete head branch when merging（仓库 Settings → Options） - 如果用了自定义 workflow 触发部署，确保它不依赖分支存在；很多脚本会用
git checkout <branch></branch>，而分支已删就会失败 - 定期用
git fetch -p清理本地 stale tracking branches，避免git branch -a列出一堆已不存在的远程分支
main 的健康度当作最高优先级来维护——CI 红了不修、部署脚本硬编码、环境配置游离在仓库外，这些细节比流程图重要得多。
