用途：在提交、创建分支、开 PR 或决定合并/分支策略时提供规范流程。
工作流选择：单人或原型且 CI 强可用主干直推；团队、开源与需代码评审默认 GitHub Flow（功能分支→PR→合并→删除分支）；传统 Git Flow（develop/release/hotfix）被认为对多数项目过时。
分支命名：格式 <type>/<scope-or-summary>，kebab-case，总长小于 50 字符，不加个人前缀，不用纯 issue 编号。类型含 feat/、fix/、chore/、docs/、refactor/、perf/、test/、ci/、build/、style/。
受保护分支：main、master、develop、production 禁止直接提交；检测到受保护分支会阻止并建议自动命名的功能分支，例外为无远程的原型、显式跳过或提交后版本递增。
分支生命周期：git checkout -b feat/<scope>，提交后 git push -u origin feat/<scope>，gh pr create，评审与 CI，gh pr merge --merge --delete-branch。分支尽量短期（最好少于 3 天）。
合并策略：默认真实合并提交；rebase 合并用于需保留的原子提交；squash 与提交后打标签不兼容，故不用。合并前必须确认 CI 检查：仓库有必需检查时用 gh pr merge <pr> --auto --merge --delete-branch；有检查但非必需时先轮询注册再 gh pr checks "$pr" --watch && gh pr merge "$pr" --merge --delete-branch，切勿对最终检查加管道以免吞掉退出码；确认零 CI 才可直接合并。仅在合并完成后于 main 打 vX.Y.Z 标签并推送，再观察标签触发的发布工作流到全绿并核对注册表版本。
合后：删除分支，git checkout main && git pull --ff-only origin main，再删除本地分支。提供 PR 模板（摘要、变更、测试计划、破坏性变更）。
反模式：长期分支、在 main 上直接提交、强推 main、无意义分支名、无描述 PR、无评审自行合并、陈旧分支。单独开发者仍建议用功能分支。发布日期、收费等信息暂未提供。