工作流不是工具而是约定。常见模型：主干开发（trunk-based，大家都往 main 提，配 feature flag 与短分支）、Git Flow（main/develop/feature/release/hotfix 五条分支，流程重，适合有明确发布周期的产品）、GitHub Flow（main + 短命 feature 分支 + PR 合并，最流行的轻量方案）。选型取决于发布节奏与团队规模。
无论哪种模型，现代实践有几条共同点：feature 分支短命（一两天合并）；main 永远可部署、保护分支禁止直推；合并前 PR 上做 Code Review 与 CI；提交信息走 Conventional Commits 自动生成 CHANGELOG。工作流的价值不在复杂，而在让 CI/CD、版本发布、代码审查都搭在同一条轨道上。
// 约定式提交（Conventional Commits）配合标准工作流： // git checkout -b feat/login-page // git commit -m "feat: 新增登录页面" 见 type 说明： // feat 新功能 // fix 修 bug // docs 文档 // style 格式（不影响逻辑） // refactor 重构 // test 测试 // chore 杂务/构建 // git push -u origin feat/login-page // → 发起 Pull Request → CI 通过 + Review → 合并 main → 删分支 // 保护分支策略（仓库设置）： // - main 禁止直推，必须走 PR // - PR 至少 1 个 approve 且全部检查通过 // - main 合并即触发部署流水线