代码流转与分支

简介

Zephyr Git 仓库有三种类型的分支：

main

包含最新的开发状态

collab-\*

协作分支用于共同开发新功能，待功能准备就绪后将其引入 main 分支。创建新的协作分支需要说明理由并获得 TSC 批准。协作分支必须基于 main 分支创建，在协作分支中开发的所有更改都必须以主开发分支为目标。对于已发布的 Zephyr 版本，经 TSC 批准引入的修复和新功能必须通过向后移植拉取请求完成。

vx.y-branch

用于跟踪基于某个主要版本的维护版本的分支

在功能进入主线之前，先在协作分支中进行开发，可以让团队独立开展子系统或功能的开发工作，提高效率并缩短周转时间，同时促进协作，简化开发者之间的沟通。

提交到协作分支的更改可以先在分支中逐步演进和完善，再提交到主线代码树进行最终集成。

为复杂功能设立独立分支，可以在将新增内容集成到正式项目之前，围绕这些内容展开深入讨论。

协作分支是临时性的，协作工作完成后必须将其删除。申请创建分支时，提案应包含以下内容：

• 明确将协作分支中的更改合并回 main 分支所需满足的退出条件。

• 为分支的预期生命周期制定时间表。建议选择一个 Zephyr 发布版本作为时间节点。延长此时间表需要获得 TSC 批准。

角色与职责

协作分支负责人承担以下职责：

• 使用项目提供的基础设施和工具（GitHub、Git）

• 对协作分支的所有更改都必须通过 GitHub 拉取请求提交。

• 仅在基于 main 分支进行变基时，才允许强制推送协作分支。

• 审查团队成员提交的更改，并在提交更改时请求分支负责人进行审查。

• 保持分支与上游同步，并定期更新。

• 使用以下方式频繁向上游推送更改：

  • GitHub 拉取请求：例如，本地分支（单人开发分支）中的更改尚未经过审查时。

  • 合并请求：在本地分支中完成一组更改，并已在协作分支中完成审查和测试时。