connectedhomeip 项目管理流程全解Matter SDK 的 Issues、Milestone、Release 与分支治理实践【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeipMatter前身 Project CHIP仓库名为 connectedhomeip作为一个由 Connectivity Standards Alliance 主导、横跨数十个硬件平台与数百个子系统的开源 SDK其工程管理方式直接影响着每一位贡献者的协作效率。本文以仓库根目录下的 docs/PROJECT_FLOW.md 为骨架系统讲解 Matter 如何使用 GitHub Projects、Issues、Milestones、Releases 与 Branches 组织程序级/项目级管理工作并结合 docs/contributing/pull_request_guidelines.md、CONTRIBUTING.md、.github/下的 Issue/PR 模板与 Workflow 配置等仓库证据进行纵深解读。读完本文你将掌握 Matter SDK 的协作规范、Issue/PR/Milestone 的用法边界、发布版本号生成逻辑如v1.2.0.x、release 分支的只修不增策略以及这一切是如何被 CI 机器人强制执行、如何沉淀进 Release Notes 的。一、总览Matter 用 GitHub 原生能力管理一个超大仓库Matter 仓库的日常运营依赖五类 GitHub 原生机制Issues承载问题描述与功能请求是所有 PR 工作的合法前提Pull Requests小而聚焦的代码变更通过审查与 CI 后合入 masterMilestones对预期截止日期或发布的标记用于团队排期Projects跨 Issue/PR/Note 的大型工作集合用于跟踪消减进度或分类投入方向Branches / Releasesmaster 永远是最新最好的分支release 分支冻结后只接受先在 master 落地的修复。仓库根目录的 CONTRIBUTING.md 进一步给出了宏观协作框架Matter 采用 Fork-and-Pull 模型任何合并至少需要 3 个来自 unique require-reviewers 列表的批准且全部 CI 通过还提供了Fast Track快速通道由 Development Lead/Vice Lead 设定 label用于加速琐碎改动。而 docs/PROJECT_FLOW.md 则聚焦描述 Issue → Milestone → PR → Release 这条主链路的日常规则是理解 Matter 开发节奏的核心文档。二、Issues一切工作的合法性起点2.1 Issues 的定位在 Matter 中Issue 被用作简单的问题描述或功能请求。原则上仓库中所有以 PR 形式提交的工作都应当处于某个已打开 Issue 的保护伞之下under the auspices of some open issue。这一要求看似繁琐甚至重复因此 PROJECT_FLOW 给出了可以不开 Issue 直接提 PR的豁免判断标准场景是否可以不开 Issue琐碎修复Trivial fixes可以。Issue 可当作 TODO 列表/提醒但有时修复所需的工作量比写 Issue 还小由一个 PR 解决的 Issue注意这类 Issue 可能实际上并未被修复或者后续回归跨多个 PR 的大任务应该开。PR 应尽可能小一个任务可以拆成多个 PR共用一个 Issue 追踪需要有 Release 可见性的修复务必开 Issue。Issue 是 Release Notes 的重要来源2.2 仓库中的落地证据Issue 模板与自动化Matter 在 .github/ISSUE_TEMPLATE/ 目录准备了多达十余种场景化模板均通过config.yaml统一管理常见模板包括001-bug-report.yamlBug 报告模板强制填写复现步骤、Bug 出现频率Bug prevalence、使用的 SDK 的 GitHub hash、受影响平台多选覆盖 ameba/android/esp32/linux/nrf/python 等 17 项并提示日志请以附件形式上传不要粘贴049-trivial-fix.yaml琐碎修复模板需要选择类型注释修复/拼写修复/重命名/其他以及测试方式单元测试/YAML 测试/手动测试/CI 测试/硬件验证等080-feature-request.yaml功能请求模板标签为feature workfeature requestneeds triage其余还包括按规格版本划分的002-1.0-issue.yaml至005-1.3-issue.yaml、090-sve-issue.yaml、091-cert-blocker.yaml、097-ci-test-failure.yaml、100-documentation-issue.yaml等。这些模板大多携带needs triage标签与 PROJECT_FLOW 中每周评审新 Issue 是项目目标相呼应——新提交的 Issue 先进入待分诊队列再由维护者每周批量分配 Milestone 与优先级。三、Pull Requests小而聚焦、易审、先绿后审3.1 核心原则PROJECT_FLOW 对 PR 的要求可以浓缩为三句话小PR 应当只针对代码库中单一、具体的变更方便审查者给出yes, thats better式的肯定易审除非所有 PR 检查CI已成功通过否则不要请求审查——反复失败的 CI 会消耗审查者的耐心有出处通常应关联一个已打开的 Issue见上一节。完整细则见 docs/contributing/pull_request_guidelines.md该文档给出了更具体的清单与背景说明。3.2 PR 标题规范标题要单行描述 足够上下文。平台相关变更加平台前缀测试变更可加[TC-XXX-1.2]类标签便于过滤。文档中列出的优秀示例[Silabs] Fix compile of SiWx917 if LED and BUTTON are disabled[Telink] Update build Dockerfile with new Zephyr SHA: c05c4.....Scenes Management/CopyScene: set access as manage instead of default to match the specFix crash during DNSSD processing due to malformed packet[TC-ABC-2.3] added new python test case based on test plan反面示例过于含糊需要打开 PR 才能明白改动内容Work on issue 1234Fix android JniTypeWrappersFix segfault in BLEFix TC-ABC-1.2Update Readme3.3 PR 大小与不计入文件补丁大小主要看被更新的代码但以下内容不计入大小评估测试文件变更测试文件通常比实现还大属正常现象生成文件一般指 zzz_generated/ 下的文件、*.matter文件以及 darwin/kotlin/java/python 等generated/目录下的文件。同时强调相关的变更代码 文档 测试可以放在一起但不相关的变更严禁混入一个 PR例如顺手修无关文档拼写、一个 PR 修多个 Issue、未先有骨架 App 就直接实现完整 App。3.4 Testing 段是强制项有 CI Bot 把关pull_request_guidelines 明确要求 PR 描述中必须包含### Testing小节且有一个 CI bot 检查这一格式。仓库中的证据在 .github/workflows/pr-validation.yaml该 Workflow 在 PR 打开/同步/重开/编辑时触发用 Python 检查 PR body 是否包含### Testing字符串缺失则 CI 失败dependabot 机器人除外同时检查 PR 模板中的 HTML 占位注释含Please replace this HTML comment文本是否已删除防止提交者照抄模板不填内容。Testing 段的填写规则自动化单元测试一句added/updated unit tests即可自动化集成测试说明由哪个TC_*.yaml或TC_*.py覆盖并简述为何不做单元测试单元测试迭代更快是首选手动测试必须给出详细的测试步骤如具体跑了哪些 chip-tool 或 REPL 命令与观察到的结果并解释为何无法自动化。这一要求被刻意设计得繁琐目的是倒逼贡献者写自动化测试仅写按某个已有 PR/文档/计划测试过是不充分的琐碎变更可简写为N/A或checked new URL opens之类但这种情况很少——例如修改一个 ID 仍需要说明如何验证新 ID 生效。此外PR 中还应提供覆盖率信息是否只覆盖 happy path、哪些边界情况未覆盖项目自动化测试的目标覆盖率约为85–90%。3.5 PR Summary 的写作要点写一个TLDR改了什么、为什么改。琐碎改动可极简fixed typos 即可改动上千行时则要解释各变更区域修复崩溃/错误时说明根因与不显然时的修复方案取舍提供对审查者有价值的备注特定平台问题、遗留工作、PR 依赖、棘手代码的 gotcha说明 WHY避免只写 Fix compile error应附上报错样例与触发命令避免只写Fixes #1234让审查者再去翻 Issue哪怕有 Issue 链接也要有简短问题描述若基于测试计划或 spec issue附上其链接大改动应附设计文档链接审查者未必了解各 tiger team 的讨论背景改动公共代码时应利用 scripts/tools/ELF_SIZE_TOOLING.md 说明RAM/FLASH 开销来源技巧用Fixes #....在合并时自动关闭 Issue用#...仅引用。仓库中的 .github/PULL_REQUEST_TEMPLATE.md 即按此设计包含 Summary / Related issues / Testing 三个区块并要求在 Related issues 中写明Fixes #12345合并自动关闭或#12345仅引用。3.6 审查后更新不要 squash、不要 force-push审查意见请在一两个 commit 内解决不要 squash也不要 merge with master。理由保留 commit 历史能让审查者对比各版本 diff、确认意见是否被落实force-update 会让审查评论难以追踪。由于 Matter 合并时本身就对每个 PR 做 squash仓库历史最终仍是干净的。四、Milestones为到期日与发布版本贴标签在 Matter 语境下Milestone 只是预期截止日期或发布的标签目的是帮助贡献者及其管理者排定优先级。分为两类4.1 Date-based基于日期以截止日期命名通常是某个星期五。这种 Milestone 通常是按当前工作负载与资源猜测某事大概何时能浮出水面并完成——本质上是愿望、猜测不是承诺。4.2 Release-based基于发布以发布版本命名截止日期可能灵活、可能变更用于追踪发布阻断项release blockers。4.3 特殊 Milestone 与无 Milestone 状态Not sure when不确定何时标记那些优先级、范围或阻断状态尚未确定的 Issue。项目目标是对其进行月度评审无 Milestone 的 Issue表示尚未被纳入上述任一 Milestone 考虑项目目标是对新 Issue 进行每周评审。五、Projects容纳跨子系统、跨 Milestone 的大工程Projects 是 Issue、PR 和 Notes 的集合用于捕捉装不进单个 Issue、涉及多个子系统、可能横跨多个 Milestone的更大规模工作。Matter 用两种方式使用 Projects任务消减追踪有终点跟踪一个大任务的 burn down。构建此类 Project 时务必设定明确边界definite scope即最终会结束的一件事归类展示无明确时间范围标注更广泛的工作方向。这类 Project 可以反映 burn down 或完成百分比但主要用于查看精力花在了哪里。约束一个 Issue 可以属于任意数量的 Project但通常应只属于一个任务追踪型Project第一种以免统计口径混乱。六、Branches 与 Releasesmaster 优先release 分支只修不增PROJECT_FLOW 最后一段给出了分支与发布的核心铁律Master should always be Matters best branch. Release branches, once cut, are closed for any feature work. Software fixes for release branches must first land on master unless demonstrably infeasible.即master 永远是 Matter 最好的分支一切新功能、日常开发都合入 masterrelease 分支一旦切出即对任何功能开发关闭release 分支的软件修复必须先合入 master除非明确证明不可行例如某些平台独占的紧急修复确实无法先在 master 落地。6.1 仓库证据发布打标签与 Release Notes.github/workflows/tag-releases.yaml 展示了发布流程的一环手动触发后调用 scripts/tagging/tag_new_release.sh当前为 draft 模式生成 Release 并附带 Notes。该脚本的核心逻辑是从根目录 SPECIFICATION_VERSION 读取当前规格版本当前仓库为1.2.0用gh release list拉取最近一次非 pre-release、且匹配该规格版本的 Release取该 Release 的第 4 段作为 SDK 修订号构造形如v1.2.0.x的完整标签MAJOR.MINOR.PATCH.SDK_REVISION并将 SDK 修订号 1若规格版本包含alpha/beta/prerelease/testevent/te/sve等字样则加--prerelease参数走预发布通道。Release Notes 的分组规则定义在 .github/release.yml按 label 将 PR 归入 Highlighted Fixesrelease note标签、Security Fixessecurity、Bug Fixesbug、Bluetooth Related Changesble、Spec Alignment Changesspec、各子系统/平台/构建相关等 18 个分类并排除scripts、external dependency、documentation等标签及机器人作者如 restyled-io、github-actions 等。这正是 PROJECT_FLOW 中任何需要 Release 可见性的修复请务必开 Issue的直接受益者——Issue/PR 上的标签直接决定了它是否、以及如何出现在 Release Notes 中。6.2 发布产物的构建.github/workflows/release_artifacts.yaml 展示了 Release 的产物构建方式手动触发时输入 releaseTagWorkflow 按该 tag checkout 后在各平台容器中构建示例应用如 ESP32 的all-clusters-app、EFR32 的 Lock App再通过 scripts/helpers/upload_release_asset.py 将*.flashbundle.txt描述的烧录文件打包上传到对应 Release。6.3 分支治理的自动化配套Cherry-pick 自动化.github/workflows/cherry-picks.yaml 监听合入 master 的 PR若带有sve/request sve/cert blocker标签则自动 cherry-pick 到1.3-sve这类特殊分支并自动添加sve cherry pick标签、指定评审人——这是修复先在 master 落地、再同步到维护分支的最佳实践体现Stale 清理.github/workflows/stale.yaml 每天自动标记 180 天无活动的 Issue/PR 为 stale但不自动关闭days-before-close: -1与月度评审 Not-sure-when、每周评审新 Issue的管理节奏互补PR Checker Bot.github/workflows/pr_checker_bot.yaml 每 6 小时运行一次由 scripts/tools/pr_checker_bot.py 驱动支持--dry-run是 PR 状态检查与合并辅助的自动化底座。七、从文档到代码把管理流程映射到仓库结构如果你希望在本地仓库中按图索骥验证上述流程可以沿着以下路径逐一查看管理环节仓库中的落地文件协作总纲Fork-and-Pull、合并要求、Fast TrackCONTRIBUTING.mdIssue 模板体系Bug/Trivial/Feature/版本/SVE/Cert.github/ISSUE_TEMPLATE/ 与 config.yamlPR 模板Summary/Related issues/Testing.github/PULL_REQUEST_TEMPLATE.mdPR 编写细则标题、大小、Testing、Summarydocs/contributing/pull_request_guidelines.mdPR 格式强制校验### Testing必填.github/workflows/pr-validation.yamlRelease 打标签与版本号生成scripts/tagging/tag_new_release.sh、.github/workflows/tag-releases.yamlRelease Notes 分组规则.github/release.ymlRelease 产物构建与上传.github/workflows/release_artifacts.yaml、scripts/helpers/upload_release_asset.py维护分支同步cherry-pick 到 SVE 等分支.github/workflows/cherry-picks.yamlIssue/PR 生命周期维护.github/workflows/stale.yaml八、给贡献者的一句话总结在 Matterconnectedhomeip仓库做贡献本质上是在遵循一套以 Issue 为锚、以 master 为根、以 Release 为标的流程纪律功能与修复尽量有 Issue 背书Release 可见性的必须开、PR 保持小而聚焦并配有### Testing验证段、Milestone 只表达期望而非承诺、Projects 用来装大工程、而所有代码最终都汇聚到 masterrelease 分支则严守先 master 后分支、只修不增的铁律。理解并遵守这套流程你的 PR 不仅能更快通过审查也会更顺畅地进入 Release Notes、最终落到全球 Matter 设备的发布版本中。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 connectedhomeip 项目管理流程全解：Matter SDK 的 Issues、Milestone、Release 与分支治理实践
connectedhomeip 项目管理流程全解Matter SDK 的 Issues、Milestone、Release 与分支治理实践【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeipMatter前身 Project CHIP仓库名为 connectedhomeip作为一个由 Connectivity Standards Alliance 主导、横跨数十个硬件平台与数百个子系统的开源 SDK其工程管理方式直接影响着每一位贡献者的协作效率。本文以仓库根目录下的 docs/PROJECT_FLOW.md 为骨架系统讲解 Matter 如何使用 GitHub Projects、Issues、Milestones、Releases 与 Branches 组织程序级/项目级管理工作并结合 docs/contributing/pull_request_guidelines.md、CONTRIBUTING.md、.github/下的 Issue/PR 模板与 Workflow 配置等仓库证据进行纵深解读。读完本文你将掌握 Matter SDK 的协作规范、Issue/PR/Milestone 的用法边界、发布版本号生成逻辑如v1.2.0.x、release 分支的只修不增策略以及这一切是如何被 CI 机器人强制执行、如何沉淀进 Release Notes 的。一、总览Matter 用 GitHub 原生能力管理一个超大仓库Matter 仓库的日常运营依赖五类 GitHub 原生机制Issues承载问题描述与功能请求是所有 PR 工作的合法前提Pull Requests小而聚焦的代码变更通过审查与 CI 后合入 masterMilestones对预期截止日期或发布的标记用于团队排期Projects跨 Issue/PR/Note 的大型工作集合用于跟踪消减进度或分类投入方向Branches / Releasesmaster 永远是最新最好的分支release 分支冻结后只接受先在 master 落地的修复。仓库根目录的 CONTRIBUTING.md 进一步给出了宏观协作框架Matter 采用 Fork-and-Pull 模型任何合并至少需要 3 个来自 unique require-reviewers 列表的批准且全部 CI 通过还提供了Fast Track快速通道由 Development Lead/Vice Lead 设定 label用于加速琐碎改动。而 docs/PROJECT_FLOW.md 则聚焦描述 Issue → Milestone → PR → Release 这条主链路的日常规则是理解 Matter 开发节奏的核心文档。二、Issues一切工作的合法性起点2.1 Issues 的定位在 Matter 中Issue 被用作简单的问题描述或功能请求。原则上仓库中所有以 PR 形式提交的工作都应当处于某个已打开 Issue 的保护伞之下under the auspices of some open issue。这一要求看似繁琐甚至重复因此 PROJECT_FLOW 给出了可以不开 Issue 直接提 PR的豁免判断标准场景是否可以不开 Issue琐碎修复Trivial fixes可以。Issue 可当作 TODO 列表/提醒但有时修复所需的工作量比写 Issue 还小由一个 PR 解决的 Issue注意这类 Issue 可能实际上并未被修复或者后续回归跨多个 PR 的大任务应该开。PR 应尽可能小一个任务可以拆成多个 PR共用一个 Issue 追踪需要有 Release 可见性的修复务必开 Issue。Issue 是 Release Notes 的重要来源2.2 仓库中的落地证据Issue 模板与自动化Matter 在 .github/ISSUE_TEMPLATE/ 目录准备了多达十余种场景化模板均通过config.yaml统一管理常见模板包括001-bug-report.yamlBug 报告模板强制填写复现步骤、Bug 出现频率Bug prevalence、使用的 SDK 的 GitHub hash、受影响平台多选覆盖 ameba/android/esp32/linux/nrf/python 等 17 项并提示日志请以附件形式上传不要粘贴049-trivial-fix.yaml琐碎修复模板需要选择类型注释修复/拼写修复/重命名/其他以及测试方式单元测试/YAML 测试/手动测试/CI 测试/硬件验证等080-feature-request.yaml功能请求模板标签为feature workfeature requestneeds triage其余还包括按规格版本划分的002-1.0-issue.yaml至005-1.3-issue.yaml、090-sve-issue.yaml、091-cert-blocker.yaml、097-ci-test-failure.yaml、100-documentation-issue.yaml等。这些模板大多携带needs triage标签与 PROJECT_FLOW 中每周评审新 Issue 是项目目标相呼应——新提交的 Issue 先进入待分诊队列再由维护者每周批量分配 Milestone 与优先级。三、Pull Requests小而聚焦、易审、先绿后审3.1 核心原则PROJECT_FLOW 对 PR 的要求可以浓缩为三句话小PR 应当只针对代码库中单一、具体的变更方便审查者给出yes, thats better式的肯定易审除非所有 PR 检查CI已成功通过否则不要请求审查——反复失败的 CI 会消耗审查者的耐心有出处通常应关联一个已打开的 Issue见上一节。完整细则见 docs/contributing/pull_request_guidelines.md该文档给出了更具体的清单与背景说明。3.2 PR 标题规范标题要单行描述 足够上下文。平台相关变更加平台前缀测试变更可加[TC-XXX-1.2]类标签便于过滤。文档中列出的优秀示例[Silabs] Fix compile of SiWx917 if LED and BUTTON are disabled[Telink] Update build Dockerfile with new Zephyr SHA: c05c4.....Scenes Management/CopyScene: set access as manage instead of default to match the specFix crash during DNSSD processing due to malformed packet[TC-ABC-2.3] added new python test case based on test plan反面示例过于含糊需要打开 PR 才能明白改动内容Work on issue 1234Fix android JniTypeWrappersFix segfault in BLEFix TC-ABC-1.2Update Readme3.3 PR 大小与不计入文件补丁大小主要看被更新的代码但以下内容不计入大小评估测试文件变更测试文件通常比实现还大属正常现象生成文件一般指 zzz_generated/ 下的文件、*.matter文件以及 darwin/kotlin/java/python 等generated/目录下的文件。同时强调相关的变更代码 文档 测试可以放在一起但不相关的变更严禁混入一个 PR例如顺手修无关文档拼写、一个 PR 修多个 Issue、未先有骨架 App 就直接实现完整 App。3.4 Testing 段是强制项有 CI Bot 把关pull_request_guidelines 明确要求 PR 描述中必须包含### Testing小节且有一个 CI bot 检查这一格式。仓库中的证据在 .github/workflows/pr-validation.yaml该 Workflow 在 PR 打开/同步/重开/编辑时触发用 Python 检查 PR body 是否包含### Testing字符串缺失则 CI 失败dependabot 机器人除外同时检查 PR 模板中的 HTML 占位注释含Please replace this HTML comment文本是否已删除防止提交者照抄模板不填内容。Testing 段的填写规则自动化单元测试一句added/updated unit tests即可自动化集成测试说明由哪个TC_*.yaml或TC_*.py覆盖并简述为何不做单元测试单元测试迭代更快是首选手动测试必须给出详细的测试步骤如具体跑了哪些 chip-tool 或 REPL 命令与观察到的结果并解释为何无法自动化。这一要求被刻意设计得繁琐目的是倒逼贡献者写自动化测试仅写按某个已有 PR/文档/计划测试过是不充分的琐碎变更可简写为N/A或checked new URL opens之类但这种情况很少——例如修改一个 ID 仍需要说明如何验证新 ID 生效。此外PR 中还应提供覆盖率信息是否只覆盖 happy path、哪些边界情况未覆盖项目自动化测试的目标覆盖率约为85–90%。3.5 PR Summary 的写作要点写一个TLDR改了什么、为什么改。琐碎改动可极简fixed typos 即可改动上千行时则要解释各变更区域修复崩溃/错误时说明根因与不显然时的修复方案取舍提供对审查者有价值的备注特定平台问题、遗留工作、PR 依赖、棘手代码的 gotcha说明 WHY避免只写 Fix compile error应附上报错样例与触发命令避免只写Fixes #1234让审查者再去翻 Issue哪怕有 Issue 链接也要有简短问题描述若基于测试计划或 spec issue附上其链接大改动应附设计文档链接审查者未必了解各 tiger team 的讨论背景改动公共代码时应利用 scripts/tools/ELF_SIZE_TOOLING.md 说明RAM/FLASH 开销来源技巧用Fixes #....在合并时自动关闭 Issue用#...仅引用。仓库中的 .github/PULL_REQUEST_TEMPLATE.md 即按此设计包含 Summary / Related issues / Testing 三个区块并要求在 Related issues 中写明Fixes #12345合并自动关闭或#12345仅引用。3.6 审查后更新不要 squash、不要 force-push审查意见请在一两个 commit 内解决不要 squash也不要 merge with master。理由保留 commit 历史能让审查者对比各版本 diff、确认意见是否被落实force-update 会让审查评论难以追踪。由于 Matter 合并时本身就对每个 PR 做 squash仓库历史最终仍是干净的。四、Milestones为到期日与发布版本贴标签在 Matter 语境下Milestone 只是预期截止日期或发布的标签目的是帮助贡献者及其管理者排定优先级。分为两类4.1 Date-based基于日期以截止日期命名通常是某个星期五。这种 Milestone 通常是按当前工作负载与资源猜测某事大概何时能浮出水面并完成——本质上是愿望、猜测不是承诺。4.2 Release-based基于发布以发布版本命名截止日期可能灵活、可能变更用于追踪发布阻断项release blockers。4.3 特殊 Milestone 与无 Milestone 状态Not sure when不确定何时标记那些优先级、范围或阻断状态尚未确定的 Issue。项目目标是对其进行月度评审无 Milestone 的 Issue表示尚未被纳入上述任一 Milestone 考虑项目目标是对新 Issue 进行每周评审。五、Projects容纳跨子系统、跨 Milestone 的大工程Projects 是 Issue、PR 和 Notes 的集合用于捕捉装不进单个 Issue、涉及多个子系统、可能横跨多个 Milestone的更大规模工作。Matter 用两种方式使用 Projects任务消减追踪有终点跟踪一个大任务的 burn down。构建此类 Project 时务必设定明确边界definite scope即最终会结束的一件事归类展示无明确时间范围标注更广泛的工作方向。这类 Project 可以反映 burn down 或完成百分比但主要用于查看精力花在了哪里。约束一个 Issue 可以属于任意数量的 Project但通常应只属于一个任务追踪型Project第一种以免统计口径混乱。六、Branches 与 Releasesmaster 优先release 分支只修不增PROJECT_FLOW 最后一段给出了分支与发布的核心铁律Master should always be Matters best branch. Release branches, once cut, are closed for any feature work. Software fixes for release branches must first land on master unless demonstrably infeasible.即master 永远是 Matter 最好的分支一切新功能、日常开发都合入 masterrelease 分支一旦切出即对任何功能开发关闭release 分支的软件修复必须先合入 master除非明确证明不可行例如某些平台独占的紧急修复确实无法先在 master 落地。6.1 仓库证据发布打标签与 Release Notes.github/workflows/tag-releases.yaml 展示了发布流程的一环手动触发后调用 scripts/tagging/tag_new_release.sh当前为 draft 模式生成 Release 并附带 Notes。该脚本的核心逻辑是从根目录 SPECIFICATION_VERSION 读取当前规格版本当前仓库为1.2.0用gh release list拉取最近一次非 pre-release、且匹配该规格版本的 Release取该 Release 的第 4 段作为 SDK 修订号构造形如v1.2.0.x的完整标签MAJOR.MINOR.PATCH.SDK_REVISION并将 SDK 修订号 1若规格版本包含alpha/beta/prerelease/testevent/te/sve等字样则加--prerelease参数走预发布通道。Release Notes 的分组规则定义在 .github/release.yml按 label 将 PR 归入 Highlighted Fixesrelease note标签、Security Fixessecurity、Bug Fixesbug、Bluetooth Related Changesble、Spec Alignment Changesspec、各子系统/平台/构建相关等 18 个分类并排除scripts、external dependency、documentation等标签及机器人作者如 restyled-io、github-actions 等。这正是 PROJECT_FLOW 中任何需要 Release 可见性的修复请务必开 Issue的直接受益者——Issue/PR 上的标签直接决定了它是否、以及如何出现在 Release Notes 中。6.2 发布产物的构建.github/workflows/release_artifacts.yaml 展示了 Release 的产物构建方式手动触发时输入 releaseTagWorkflow 按该 tag checkout 后在各平台容器中构建示例应用如 ESP32 的all-clusters-app、EFR32 的 Lock App再通过 scripts/helpers/upload_release_asset.py 将*.flashbundle.txt描述的烧录文件打包上传到对应 Release。6.3 分支治理的自动化配套Cherry-pick 自动化.github/workflows/cherry-picks.yaml 监听合入 master 的 PR若带有sve/request sve/cert blocker标签则自动 cherry-pick 到1.3-sve这类特殊分支并自动添加sve cherry pick标签、指定评审人——这是修复先在 master 落地、再同步到维护分支的最佳实践体现Stale 清理.github/workflows/stale.yaml 每天自动标记 180 天无活动的 Issue/PR 为 stale但不自动关闭days-before-close: -1与月度评审 Not-sure-when、每周评审新 Issue的管理节奏互补PR Checker Bot.github/workflows/pr_checker_bot.yaml 每 6 小时运行一次由 scripts/tools/pr_checker_bot.py 驱动支持--dry-run是 PR 状态检查与合并辅助的自动化底座。七、从文档到代码把管理流程映射到仓库结构如果你希望在本地仓库中按图索骥验证上述流程可以沿着以下路径逐一查看管理环节仓库中的落地文件协作总纲Fork-and-Pull、合并要求、Fast TrackCONTRIBUTING.mdIssue 模板体系Bug/Trivial/Feature/版本/SVE/Cert.github/ISSUE_TEMPLATE/ 与 config.yamlPR 模板Summary/Related issues/Testing.github/PULL_REQUEST_TEMPLATE.mdPR 编写细则标题、大小、Testing、Summarydocs/contributing/pull_request_guidelines.mdPR 格式强制校验### Testing必填.github/workflows/pr-validation.yamlRelease 打标签与版本号生成scripts/tagging/tag_new_release.sh、.github/workflows/tag-releases.yamlRelease Notes 分组规则.github/release.ymlRelease 产物构建与上传.github/workflows/release_artifacts.yaml、scripts/helpers/upload_release_asset.py维护分支同步cherry-pick 到 SVE 等分支.github/workflows/cherry-picks.yamlIssue/PR 生命周期维护.github/workflows/stale.yaml八、给贡献者的一句话总结在 Matterconnectedhomeip仓库做贡献本质上是在遵循一套以 Issue 为锚、以 master 为根、以 Release 为标的流程纪律功能与修复尽量有 Issue 背书Release 可见性的必须开、PR 保持小而聚焦并配有### Testing验证段、Milestone 只表达期望而非承诺、Projects 用来装大工程、而所有代码最终都汇聚到 masterrelease 分支则严守先 master 后分支、只修不增的铁律。理解并遵守这套流程你的 PR 不仅能更快通过审查也会更顺畅地进入 Release Notes、最终落到全球 Matter 设备的发布版本中。【免费下载链接】connectedhomeipMatter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.项目地址: https://gitcode.com/GitHub_Trending/co/connectedhomeip创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考