主干开发与持续集成
主干开发与持续集成的配合方式：每次合入都触发完整流水线，主干始终保持在可构建、可发布的状态；失败的构建要立刻修复或回滚。它是主干模式能够成立的前提，而不是可选的附加项。
基本信息
| 要求 | 主干随时可构建、可交付 |
|---|---|
| 门禁 | 自动化检查全部通过才允许合入 |
| 节奏 | 小批量、高频次，问题暴露得更早 |
| 失败处理 | 优先修复，必要时回滚以保持主干可用 |
| 覆盖范围 | 单元测试、静态检查、构建与部署验证 |
典型使用场景
- 团队采用主干开发模式，需要配套的自动化
- 要求主干随时可以发布
- 希望问题尽早暴露在流水线而不是线上
- 合入前需要自动化门禁把关
- 减少合并之后才发现的主干故障
流水线要点
流水线要点
# 合入前：单元测试与静态检查，快速反馈
# 合入后：构建并部署到预发环境验证
# 失败时：优先修复，必要时回滚保持主干可用
git switch main && git pull --ff-only # 让本地与主干保持一致
git log --oneline -5 # 确认最新主干状态符合预期环节与要求
| 环节 | 要求 |
|---|---|
| 合入前检查 | 快速反馈，覆盖核心路径 |
| 合入后验证 | 构建与部署验证主干可用 |
| 失败处理 | 限时修复或回滚 |
| 反馈速度 | 从提交到拿到结果的时间要短 |
持续集成的核心价值是快速反馈：提交到拿到结果的时间越短，问题定位的成本越低。
流水线耗时长时应拆成快慢两类检查，把快速检查作为合入门禁，慢速检查在合入后继续运行。
主干长时间处于失败状态会侵蚀团队信任，宁可回滚也要先让主干恢复可用。
预发环境验证能拦住只在集成后才出现的问题，但环境本身要与生产的差异保持可控。