本文面向核心维护者与高频贡献者，与 贡献指南、提交与 PR 规范一起阅读。目标是在欢迎贡献的同时，尽量避免大量不可控、难回滚的改动，降低 main 与下游 fork 被拖离稳定形态的风险。
- 小步、可审、可回滚：宁可多几个聚焦的 PR，也不要一个巨型「一锅端」难以评审的变更。
- 先对齐意图再写代码：涉及行为或数据契约的改动，尽量先在 Issue / Discussion 里对齐范围，再开 PR。
- 守住核心路径：数据层、路由、全局配置、构建与导出链路影响全站——PR 中应写清动机、风险与验证方式。
- 禁止夹带无关重构：不要把大范围重命名、整仓格式化、大版本依赖升级与无关 bugfix/功能混在同一 PR；必要时拆分。
- 依赖与工具链：框架大版本、锁文件策略类变更需说明理由、破坏性变更与回归验证（构建、关键路径测试等）。
| 类型 | 建议 |
|---|---|
| Bug 修复 | 最小改动 + 测试或可复现说明 |
| 小功能 / 单主题 | 尽量限制在主题目录或单一模块边界，避免顺手改共享层 |
| 跨主题 / 公共 API | 先在 Issue 对齐接口与默认值，迁移路径写进文档 |
| 破坏性变更 | 写清版本与配置迁移；必要时拆阶段便于评审 |
以下改动往往影响全站或多主题——PR 描述与验证说明应更完整（是否必须双人评审由仓库所有者与维护者共同约定）：
lib/db/（含SiteDataApi、Notion 拉取与缓存）pages/下的 SSG/ISR、i18n、构建生命周期相关逻辑next.config.js与导出/构建脚本- 全局配置（
blog.config.js、lib/config.js及同类默认行为） - 安全相关：鉴权、密钥、第三方回调、CSP 等
- 小众站点假设尽量做成可选项或配置项，避免写进影响所有人的全局默认。
- 主题隔离：主题专属逻辑放在
themes/<name>/，避免把某一主题的 UI 或路由假设写进共享层。 - 文档同步：用户可见行为或配置项变更时，在同一 PR 或紧随其后的 PR 中更新文档（中英视情况）。
仓库所有者（个人仓库的拥有者，或组织的 Owner）可在 Settings → Collaborators（或组织下的 Teams / Repository access）邀请信任的维护者（例如 @qianzhu18），并按信任程度授予 Write / Maintain / Admin 等角色；是否需要能改分支保护、管理部分仓库设置，决定选 Maintain 还是 Admin。
若 分支保护 或 第三方检查（如部署需授权）经常导致无法合并，可在 Settings → Branches 中为受信维护者配置 bypass，或由所有者与维护者书面约定在何种情况下由谁代为合并。
GitHub 界面文案会随产品迭代变化；谁可以合并、何时允许绕过检查等治理规则，建议在维护者之间留下文字共识（Issue、Discussion 或本仓库文档的修订说明），而不要仅依赖默认设置。
本文档随项目演进可修订；重大修订建议在 Issue 或 Discussion 中留一句背景，便于后来者理解。