Git 事件触发 CI/CD 流水线（GitHub Actions、GitLab CI、Jenkins 等均通用）。以下是业界最主流的 5 套模板，覆盖测试环境持续部署、生产正式发布、预发灰度、热修复、上线回滚全场景，拿来即可直接套用。
一、主干推送自动部署流（测试/开发环境首选）
适用场景：开发环境、测试环境的持续集成部署，代码合并主干后自动更新，是敏捷迭代团队的标配方案
触发规则：监听 main/master 分支的 push 事件，自动执行「构建 → 单元测试 → 部署测试环境」
# 1. 基于最新主干创建功能分支
git checkout main
git pull origin main
git checkout -b feature/订单列表优化
# 2. 本地开发提交，推送远程分支
git add .
git commit -m "feat: 优化订单列表分页查询性能"
git push origin feature/订单列表优化
# 3. 在代码平台发起 PR，评审通过后合并到 main
# ✅ 合并完成瞬间，CI/CD 自动触发测试环境全量部署二、语义化标签触发生产发布流（生产环境标准方案）
适用场景：正式生产环境发布，是目前互联网团队最通用的生产上线模式，版本可追溯、风险可控
触发规则：监听 v..* 格式的标签推送事件，自动执行「生产构建 → 全量校验 → 部署生产环境」
核心约定：打标签 = 执行上线操作，标签号遵循 SemVer 语义化规范（主版本.次版本.修订号）
# 1. 切换到主干，拉取测试验证通过的待发布代码
git checkout main
git pull origin main
# 2. 打正式版本附注标签（必须带发布说明，方便追溯）
# 版本规则：
# - 主版本：不兼容的重大架构/API变更
# - 次版本：向下兼容的新功能新增
# - 修订号：向下兼容的bug修复
git tag -a v1.2.0 -m "Release v1.2.0：新增订单导出功能、优化首页加载速度"
# 3. 推送标签到远程仓库
# ✅ 标签推送成功后，CI/CD 自动触发生产环境全量上线流程
git push origin v1.2.0注意：不推荐使用
git push origin --tags批量推送，避免误推测试标签触发生产部署。
三、发布分支+预发灰度上线流（中大型项目专用）
适用场景：有独立预发布/灰度环境的中大型项目，先在预发验证，再全量生产上线
触发规则：
release/*分支推送 → 自动部署到预发布/灰度环境- 正式版本标签推送 → 自动部署到全量生产环境
# 1. 基于主干创建发布分支，命名规范：release/版本号
git checkout main
git pull origin main
git checkout -b release/v1.2.0
# 2. 推送发布分支到远程
# ✅ 自动触发：部署到预发布/灰度环境，供测试、产品验收
git push origin release/v1.2.0
# 3. 预发验证发现小问题，直接在release分支修复并推送
git add .
git commit -m "fix: 修复预发环境导出接口超时问题"
git push origin release/v1.2.0
# 推送后自动更新预发布环境，无需手动操作
# 4. 预发验收通过，合并到主干并打正式标签
git checkout main
git merge --no-ff release/v1.2.0 -m "merge: 发布 v1.2.0 正式版本"
git tag -a v1.2.0 -m "Release v1.2.0 正式全量发布"
# 5. 推送主干和正式标签
git push origin main
# ✅ 标签推送后，触发生产环境全量上线
git push origin v1.2.0
# 6. 收尾：同步到开发分支、清理发布分支
git checkout develop
git merge main
git push origin develop
git branch -d release/v1.2.0
git push origin --delete release/v1.2.0四、热修复自动上线流（线上紧急bug）
适用场景：生产环境突发故障，需要快速修复并自动上线
触发规则：热修复分支合并主干 + 推送补丁标签，自动触发生产环境部署
# 1. 基于生产主干创建热修复分支
git checkout main
git pull origin main
git checkout -b hotfix/支付回调签名异常
# 2. 修复问题并提交，推送远程
git add .
git commit -m "fix: 修复支付回调签名校验失败导致的掉单问题"
git push origin hotfix/支付回调签名异常
# 可选配置：hotfix 分支自动部署到测试/预发环境验证
# 3. 验证通过后合并到主干，打补丁版本标签
git checkout main
git merge --no-ff hotfix/支付回调签名异常 -m "merge: 线上支付掉单问题热修复"
git tag -a v1.2.1 -m "Hotfix v1.2.1：修复支付回调签名异常"
# 4. 推送主干和补丁标签
git push origin main
# ✅ 标签推送后，自动触发生产环境热修复上线
git push origin v1.2.1
# 5. 同步修复代码到开发分支，避免后续版本遗漏bug
git checkout develop
git cherry-pick <修复提交的commit哈希>
git push origin develop
# 6. 清理临时分支
git branch -d hotfix/支付回调签名异常
git push origin --delete hotfix/支付回调签名异常五、上线失败·自动化回滚操作模板
核心原则：不篡改提交历史，通过新标签/新提交触发回滚部署，保证流水线可追溯
方案1：版本标签回滚（最快，无代码变更）
适合上线后立即发现问题，直接回退到上一个稳定版本
# 1. 查看所有历史版本标签，确认上一个稳定版本
git tag
# 示例：上一个稳定版本为 v1.1.9
# 方式A（推荐）：直接在 CI/CD 平台重新运行 v1.1.9 的部署流水线，无需修改Git代码
# 方式B：打回滚专属标签，保留回滚操作记录
git tag -a v1.2.0-rollback -m "回滚：v1.2.0 上线异常，回退到 v1.1.9 稳定版本"
git push origin v1.2.0-rollback
# 流水线可配置识别回滚标签，自动部署对应版本代码方案2：代码级回滚（生成反向提交）
适合需要部分回滚、保留其他新功能的场景
# 1. 找到出错的提交哈希
git log --oneline
# 2. 生成反向提交，撤销对应错误改动
git revert <出错的提交哈希> -m "revert: 回滚订单导出功能，上线导致接口超时"
# 3. 打补丁标签推送，触发自动部署
git tag -a v1.2.1 -m "回滚补丁：撤销 v1.2.0 导出功能"
git push origin main
git push origin v1.2.1六、CI/CD 联动常用 Git 技巧
- 跳过 CI 流水线
修改文档、注释等无需构建的内容时，提交信息加关键字即可跳过流水线
git commit -m "docs: 更新README部署说明 [skip ci]"通用关键字：[skip ci]、[ci skip]、[no ci]，GitHub/GitLab 均原生支持。
- 指定环境部署
很多团队通过分支前缀触发对应环境，无需手动操作平台
# 将本地代码推送到远程部署分支，触发对应环境部署
git push origin feature/xxx:deploy/test # 部署测试环境
git push origin feature/xxx:deploy/staging # 部署预发布环境