HX返回个人主页

Git Workflow / 11

Git 流程环境映射

Git 规范的重点，是让分支、环境、提测、上线和 Tag 形成一条可追溯的发布路径。

公开摘要

分支与环境映射

  • master：线上生产环境。
  • beta：线上测试环境。
  • dev/{日期}/{需求}：需求开发分支，全部小写。
  • fix/{日期}/{需求}：缺陷修复分支，全部小写。

开发分支必须从 master 创建；前后端必须使用统一分支名；当 master 有更新时，开发分支必须及时合并最新 master。

标准流程

完整链路是：创建分支 → 开发自测 → 提测合并 beta → 上线合并 master → 打 Tag。

  1. 创建需求分支：切到 master，拉取最新代码，再创建 dev/20260413/feature-name。
  2. 多人协作时，如果 master 有更新，先更新主干，再合并到当前开发分支。
  3. 开发完成后提交并推送，例如使用 feat: 完成 feature-name 需求 这类语义化提交说明。
  4. 提测时合并需求分支到 beta 并推送。
  5. 测试通过后合并需求分支到 master 并推送。
  6. 上线后按版本创建并推送 Tag，例如 v2.6。
不要出现 test → dev、dev → pre 这类跨环境反向合并；并行项目下会污染环境。

Tag 与回写

上线后如果主干发生变化，按需将 master 回写到 beta，并提醒仍在开发中的 dev/* 或 fix/* 分支同步最新主干。

补充约束

  • 提测前至少完成本地自测。
  • 一个需求对应一个 dev/* 分支，一个修复对应一个 fix/* 分支。
  • 不要在 master、beta 上直接开发。
  • 分支命名和提交说明尽量语义化，便于追溯与审计。