用途
该技能记录了如何在 GitHub 上协作开发项目，聚焦于贡献代码、创建 PR、审查代码和管理 issues 的规范流程。
主要能力
- 区分不同的项目访问权限，给出相应的协作方式。
- 说明提交改动的分支与 PR 流程。
- 说明如何在 GitHub PR 上进行代码审查。
- 说明如何回应审查意见。
- 说明 PR 合并后的同步操作。
- 说明 issues 应创建在哪个仓库。
使用方式
在项目上工作
- 拥有写入权限：可以直接在项目中工作。
- 仅拥有只读权限，无法直接向任何分支写入：在自己的 GitHub 用户账户下创建一个 fork，只在 fork 上工作，而不是在原仓库上，fork 即是所有开发工作的工作区。
提交改动
向项目提交改动时：
- 创建一个新分支（绝不要直接提交到 main）。
- 随着工作推进，在该分支上进行提交。
- 准备好后，从工作分支向 main 分支创建 PR（如果是 fork，则是从一个仓库到另一个仓库）。
代码审查
当被要求审查代码时：
- 直接在 GitHub PR 上进行审查。
- 在代码中合适的位置添加行内评论。
- 一般性 PR 评论仅用于总体性反馈。
回应审查意见
回应审查反馈时：
- 在 GitHub 上回应评论，而不仅仅在代码中处理。
- 逐条回复每个评论，说明做了什么改动或为什么保留某项内容。
- 在反馈得到处理后，将对话标记为已解决。
PR 合并之后
一旦 PR 被合并：
- 切换回 main 分支。
- 从 origin 拉取，以同步已合并的改动。
Issues
始终在原仓库上创建 GitHub issues，绝不要在 fork 上创建。fork 仅在需要时用于开发工作。
适用场景
- 需要向 GitHub 项目贡献代码时。
- 需要创建或处理 PR 时。
- 需要审查代码或回应审查意见时。
- 需要管理或创建 issues 时。
限制
资料中未提供关于权限获取方式、分支命名规范、提交信息格式、PR 模板、审查响应时限或其他具体工具要求的进一步说明。