推出 GitHub Issues 集成
2020 年 5 月 6 日,作者:Alex Ross,@alexr00
在 Visual Studio Code 团队中,我们使用 GitHub issues 来跟踪我们的所有工作。从我们详细的迭代计划到各个错误,我们都将所有内容作为 GitHub issues 进行跟踪。鉴于 issues 对于我们的团队和其他 GitHub 项目的重要性,我们希望在 VS Code 中添加 GitHub issues 集成。此添加是对我们一年多前宣布的 GitHub Pull Request 工作的补充。从 VS Code 1.45 版本开始,此新支持将 issues 和源代码更紧密地结合在一起,可在GitHub Pull Requests 和 Issues扩展(以前名为 GitHub Pull Requests)中使用。
我们的集成方法
Issues 和 pull requests 通常是紧密相连的,因此将它们包含在同一个GitHub Pull Requests 和 Issues扩展中是合乎逻辑的一步,因为 issues 和 pull requests 都需要很多相同的GitHub API。我们不想将 GitHub 功能直接添加到 VS Code 编辑器的核心,因为有很多源代码控制选项。相反,当检测到用户的打开的存储库使用 GitHub 时,我们会推荐该扩展。通过使用我们自己的扩展 API,我们确保该 API 具有扩展作者需要的功能,并且其他存储库提供商可以实现类似的集成。
重要的是,我们不要规定过于具体的工作流程。相反,我们的目标是以灵活的方式将 issues 带入内部开发循环。例如,在代码注释中为 issue 提供更多上下文是该目标的一部分,但是将完整的 issue 管理添加到 VS Code 中不太合适。我们不想重新发明 GitHub 已经做得很好的 UI。我们确实想建立尚未存在的连接。
代码上下文中的 Issues
在源代码中链接到 issues 是我们工作流程的正常组成部分,尤其是在某些逻辑难以理解或存在需要采取措施的 //TODO 注释时。如果你在 VS Code 存储库中搜索 issue 引用,你会看到很多提到的 issues。尽管链接提供了指向更多信息的指针,但是要真正了解更多信息,你需要离开编辑器。现在,通过悬停获得此 issue 上下文,你无需中断流程即可了解更多信息。
Issue 悬停适用于完整的 issue URL、issue 注释 URL、按编号引用的 issues (#1234
) 以及按 owner/repository#1234
引用的 issues(例如 Microsoft/vscode#1234
)。我们还经常在我们的代码库中引用用户。VS Code proposed API 包含许多开发人员引用,以清楚地表明谁负责这些建议。
Issue 上下文通常需要在提交消息中引用提交解决的 issue、在源代码文件中以及在 Markdown 中(例如,更改日志)。为了轻松添加此上下文,我们为 issues 和用户添加了完成建议。在 Git 提交文本框中,你可以使用 githubIssues.issueCompletionFormatScm
设置来格式化你的 issue 完成。在 Markdown 文件中,issues 以 Markdown 链接的形式完成,而在其他文件中,issues 以简单的 issue 编号 (#1234
) 的形式完成。
可以使用设置 githubIssues.queries
配置可能的 issues 列表,因此,如果你跨多个存储库工作,则可以包含对这些 issues 的查询。这些查询使用GitHub 搜索语法。用户列表包括当前打开的存储库中的协作者。
从任何地方创建 Issue
当我们在处理某些源代码时在 VS Code 中发现错误时,我们会创建一个 issue 并将其分配给拥有该区域的人。或者,如果发现该错误的人也是所有者,我们通常会留下 //TODO 注释以提醒自己回头解决。当你有许多贡献者时,散落在代码库中的 //TODO 很难跟踪(尽管可以肯定地说,我们都这样做过),但是创建 issue 并在 //TODO 中引用它是可跟踪的。为了减少在你深入源代码时创建 issue 的障碍和上下文丢失,有几种创建 issue 的新方法
从 //TODO 注释(可以使用 githubIssues.createIssueTriggers
配置)中,你可以创建并分配 issue,而无需离开 VS Code。
从选定的内容中,你可以使用 GitHub Issues:从选定内容创建 Issue 命令快速创建一个 issue,其中包含指向其原始源代码的永久链接。如果你只需要指向某些代码的指针,你还可以使用 GitHub Issues:复制 GitHub 永久链接命令。最后,如果终端中存在失败信息,你只需将输出复制到剪贴板,然后使用 GitHub Issues:从剪贴板创建 Issue 创建一个 issue。
处理 Issues
一个常见的工作流程是查看你的 issues,选择一个要处理的 issue,创建一个工作分支,进行一些提交,然后通过 pull request 将更改合并回主分支。从新的 Issues 视图中,你可以完全按照此操作进行。
为了适应更多的工作流程,你可以配置几个选项。如果你的工作流程不涉及创建主题分支,则可以使用 githubIssues.useBranchForIssues
禁用分支创建。如果你的分支有不同的命名方案,则可以使用 githubIssues.issueBranchTitle
设置。可以使用 githubIssues.queries
使用自定义查询配置 Issues 视图中列出的 issues。
想了解更多?
你可以观看 Sana Ajani (@sana_ajani) 和 Burke Holland (@burkeholland) 在 GitHub Satellite 上进行的 每个 GitHub 用户都应该了解的关于 VS Code 的知识 演讲。
你还可以阅读使用 GitHub 主题,其中更详细地描述了 VS Code 的 GitHub 集成。
展望未来
目前,大多数这些功能仅在存储库克隆(而非 fork)中受支持,因此还有更多工作要做,以支持这种情况和其他用例。我们很想看到你对此扩展的反馈,因此请随时在扩展的存储库中的 issues 中留下你的建议!
祝你编码愉快!
Alex Ross,VS Code 开发人员 @alexr00