git是自动化部署的单一可信源，通过管理配置、iac、ci/cd脚本等实现可追溯发布；分支策略（main/release/feature）驱动环境隔离与发布节奏；git事件触发自动化流水线并内置健康检查与回滚机制。
自动化部署配置离不开 Git 版本控制的支撑，它不只是存代码的地方，更是整个发布流程的“单一可信源”。配置文件、CI/CD 脚本、环境变量模板、基础设施即代码（IaC）全部纳入 Git 管理，才能实现可追溯、可复现、可审计的自动化发布。
Git 作为配置与发布的核心枢纽
把部署配置（如 .github/workflows/deploy.yml、docker-compose.prod.yml、terraform/env/prod/）和应用代码一起提交到 Git，意味着每次发布都对应一个明确的 commit hash。这解决了“到底部署了哪个版本”的疑问，也使得回滚变成一次 git checkout + 重新触发部署的确定性操作。
- 所有环境配置（dev/staging/prod）应按目录或分支隔离，避免硬编码敏感值，改用环境注入或密钥管理服务
- 禁止在服务器上手动修改配置后不提交——这会制造“漂移”，破坏 Git 作为唯一真相源的地位
- 使用
.gitattributes或git check-ignore明确排除本地调试文件、日志、临时构建产物等非版本化内容
分支策略驱动发布节奏
分支不是随意创建的标签，而是发布流程的轨道。主流策略如 Git Flow 或简化版 Trunk-Based Development（TBD）都依赖 Git 分支定义不同阶段的行为：
- main / master 分支：对应生产环境，只允许通过 PR 合并，且必须经过 CI 测试、代码审查、自动安全扫描
- release/* 分支：用于版本冻结、补丁修复和发布前验证，打 tag 后触发生产部署流水线
- feature/* 分支：开发隔离，合并前需 rebase 到最新 main，减少集成冲突
- 每个分支可绑定专属部署目标（如 feature 分支 → 预发环境；release 分支 → 生产环境），由 CI/CD 工具自动识别并执行
自动化发布的触发与校验闭环
发布动作不应依赖人工点击，而应由 Git 事件精准驱动，并内置多层防护：
- 推送
main分支触发构建 → 测试 → 打包 → 推送镜像 → 更新 Kubernetes Deployment - Pull Request 合并到
release/v2.3自动触发灰度发布：先部署 5% 流量，运行 10 分钟健康检查（HTTP 状态码、延迟、错误率），达标则全量，否则自动回滚 - 每次部署后执行
curl -f http://app:8080/health或调用 Prometheus API 查询指标，失败立即中止并告警 - 部署日志、commit ID、镜像 digest 全部写入发布记录表或 Slack 通知，确保操作留痕
回滚与版本快照不可少
自动化发布的价值不仅在于“发得快”，更在于“退得稳”。Git 天然支持回滚，但需配套机制保障实效性：
- 每次成功部署，CI/CD 工具应自动为当前 commit 打 tag（如
v2.3.1-20260709-1422），并推送到远程仓库 - 生产环境部署脚本必须基于 tag 拉取，而非分支名（避免分支被 force push 导致不一致）
- 数据库变更需单独版本化（如 Flyway 迁移脚本），与应用代码 tag 对齐，确保回滚时 schema 与代码兼容
- 保留最近 3 个生产 tag 的部署包备份（S3 或制品库），跳过构建直接重放部署
