⚠️ 法律与用途声明：本文讨论 GitHub template repository 机制与企业仓库组织管理，基于开源工具（GitHub Actions / Conan 2），属于经验分享。所有企业名、组织名、内部仓库与账号均已脱敏。读者须遵守所在地区法律法规。
一、新仓库该长什么样
B0 讲了 metadata.json 怎么驱动一切。但一个新算法仓库刚创建的时候，谁给它放好 metadata、conanfile、CI workflow、文档骨架、测试骨架、benchmark 骨架？总不能让开发者自己一个个文件去创建。
答案就是这一篇的主题：用 GitHub 的 template repository 机制，让新仓库一键从模板创建，自带全套骨架。
但在讲模板之前，得先讲一个更基础的问题：这些仓库该放在哪、怎么管。
二、组织分层：仓库不是散养的
一个团队用 GitHub 管代码，不是把仓库随便往个人账号下一扔就完事。得有组织结构：
GitHub Organization（企业组织）
├── Team A（算法团队）
│ ├── repo-algo-vision
│ ├── repo-algo-voice
│ └── repo-algo-motion
├── Team B（平台团队）
│ ├── ci-templates
│ └── toolchain-package
└── template-repo（模板仓，全组织共享）
这棵树的每一层都有意义：
- Organization：企业级的代码容器。所有团队、所有仓库都在它下面。runner 注册到这里（A1 讲过），Conan remote 指向这里的组织级 Secrets。
- Team：按职能或业务线分组。权限按 Team 分配，而不是按个人——人走了 Team 还在，权限不用一个个回收。
- Repository：具体的代码仓库。每个仓库从模板创建，自带骨架。
权限跟着 Team 走，不跟着个人走。这条规矩看着简单，但它意味着：员工入职加入 Team 自动获得对应仓库权限，离职移出 Team 自动回收，不用管理员一个个仓库去改。
三、template repository：一键开张
组织搭好了，模板仓放在组织下、全组织共享。GitHub 有个功能叫 template repository——把一个仓库标记为模板后，点"Use this template"就能一键创建新仓库，自带模板里所有文件。
创建出来的新仓库，开箱就有 B0 讲的 metadata.json、conanfile.py、configs/build-matrix.yaml、.github/workflows/、docs/、test_package/、benchmark/——全套骨架。开发者不需要从零搭，只需要往骨架里填自己的算法。
和"复制别的仓库再改名"相比，template repository 有几个本质区别：
- 不带历史：从模板创建的仓库不继承模板的 git 历史，是一张白纸。不会把模板仓库的 commit log 带进新仓库。
- GitHub 原生支持：不需要第三方工具，GitHub UI 上一个按钮搞定。
- 可标记多个模板：组织里可以有不同类型的模板（C++ 库模板、算法 SDK 模板、工具脚本模板），新仓库选对应模板创建。
四、branch protection 和 CODEOWNERS：仓库不是想推就推
仓库创建好了，第一件事不是写代码，是把规矩立好——谁有权限推什么分支、谁必须 review。
# branch protection 规则（脱敏示意）
main:
required_pull_request_reviews:
required: 2 # 至少 2 人 review
dismiss_stale_reviews: true # 新提交自动消除旧 review
required_status_checks:
strict: true # 必须基于最新代码
contexts: ["CI / build"] # CI 必须过
enforce_admins: false # 管理员可不遵守（紧急修复用）
几条关键规则：
- PR 必须有人 review：不能自己写自己合。至少要有一双别的眼睛看过。
- CI 必须绿：PR 的 CI 全过了才能合。红灯合进去就是给自己埋雷。
- 强制基于最新：PR 必须基于 main 的最新代码，避免合进去冲突。
配合 CODEOWNERS 文件，可以做到特定路径的改动必须由特定的人 review：
# CODEOWNERS（脱敏示意）
# 核心算法代码必须算法组 review
/src/algorithms/ @team-algo
# CI 模板改动必须平台组 review
.github/workflows/ @team-platform
# 文档改动谁都可以
/docs/ @*
CODEOWNERS 的价值是让"谁负责什么"变成代码层面的约束，而不是靠人自觉。改了算法代码但没找算法组 review？GitHub 不让你合。
五、Conventional Commits：提交消息不是随便写的
最后一块拼图是提交规范。散乱的提交消息（"update"、"fix bug"、"改了点东西"）对项目维护是灾难——你回看历史，根本不知道每次改了什么。
我们要求所有提交遵循 Conventional Commits 规范：
feat: 新增 FFT 算法模块
fix: 修复 Cortex-M4 上 FPU 初始化顺序
docs: 更新 benchmark 使用说明
refactor: 抽取公共滤波器接口
chore: 升级工具链版本到 12.x
为什么这么较真提交消息？因为后续的自动版本管理（B4 会专门讲）完全依赖它。semantic-release 工具读 commit 消息里的 feat/fix/BREAKING 来判断该升 minor、patch 还是 major 版本。提交消息不规范，自动版本就废了。
规范不是洁癖，是自动化的前提。后面 B4 会展开讲自动版本管理怎么从这些规范的 commit 消息里推出版本号、生成 CHANGELOG。
六、几条攒下来的判断
组织分层不是摆设。Team 层让权限跟着团队走，不跟着个人。人走茶凉不用一个个仓库回收权限。
template repository 是模板化推广的入口。一键创建自带骨架，开发者从零搭的痛苦（A14 讲过）在这里被消灭。
branch protection 是质量的地基。PR 必须被 review、CI 必须绿——这些不是建议，是代码层面的硬约束。
CODEOWNERS 让责任落到文件。改了谁的代码就必须找谁 review，不是靠自觉，是靠机器拦。
提交规范是自动化的燃料。Conventional Commits 不是为了好看，是为了让后续的自动版本管理有数据可读。
组织即架构。仓库结构、权限、分支、提交规范——这些看起来是管理层面的事，其实本身就是开发范式的载体。把它们设计好了，团队的协作方式自然就规范了。
下一篇，我们深入 B0 讲的 metadata.json，专门拆解它的 schema 设计：metadata.json 单一数据源——每个字段为什么存在、被谁消费、怎么消除配置漂移。
参考链接：
[1] GitHub：创建 template repository https://docs.github.com/en/repositories/creating-and-managing-repositories/creating-a-template-repository
[2] GitHub：组织与团队管理 https://docs.github.com/en/organizations/organizing-members-into-teams
[3] GitHub：branch protection rules https://docs.github.com/en/repositories/configuring-a-repository/managing-branches-in-your-repository
[4] GitHub：CODEOWNERS 文件 https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
[5] Conventional Commits 规范 https://www.conventionalcommits.org/
[6] GitHub Actions：组织级 Secrets 与 Variables https://docs.github.com/en/actions/how-tos/security-for-github-actions/security-guides/using-secrets-in-github-actions