GitHub Issues連携機能の紹介
2020年5月6日 Alex Ross (@alexr00) 記
Visual Studio Codeチームでは、すべての作業をGitHub Issuesで追跡しています。詳細なイテレーション計画から個々のバグまで、すべてをGitHub Issuesとして追跡しています。Issuesが私たちのチームや他のGitHubプロジェクトにとって非常に重要であることから、VS CodeにGitHub Issues連携機能を追加したいと考えました。この追加は、1年以上前に発表したGitHub Pull Requestの作業を補完するものです。VS Codeバージョン1.45以降、Issuesとソースコードをより密接に連携させるこの新しいサポートは、GitHub Pull Requests and Issues拡張機能（以前はGitHub Pull Requestsという名前）で利用できるようになります。
連携アプローチ
Issuesとプルリクエストは密接に関連していることが多いため、同じGitHub Pull Requests and Issues拡張機能に含めるのは論理的なステップでした。Issuesとプルリクエストの両方に同じGitHub APIの多くが必要とされるためです。私たちは、多くのソースコード管理オプションがあるため、GitHubの機能をVS Codeエディタのコアに直接追加したくありませんでした。その代わりに、ユーザーの開いているリポジトリがGitHubを使用していることを検出したときに、拡張機能を推奨します。独自の拡張機能APIで作業することにより、APIが拡張機能の作者が必要とする機能を備えていることを確認し、他のリポジトリプロバイダーも同様の連携を実装できます。
特定のワークフローを過度に指定しないことが重要でした。代わりに、私たちの目標は、Issuesを柔軟な方法で内側の開発ループに取り込むことでした。たとえば、コードコメントでIssueのより多くのコンテキストを提供することはその目標の一部ですが、完全なIssue管理をVS Codeに追加することはあまり適切ではありません。GitHubがすでにうまく行っているUIを再発明したくありません。私たちは、まだ存在しないつながりを作りたいのです。
コードコンテキスト内のIssues
ソースコード内のIssuesへのリンクは、特に理解しにくいロジックがある場合や、対応が必要な//TODOコメントがある場合に、私たちのワークフローの通常の作業です。VS CodeリポジトリでIssue参照を検索すると、多くのIssueが言及されているのがわかります。リンクはより多くの情報へのポインタを提供しますが、実際に詳細を知るにはエディタを離れる必要があります。これで、ホバーを通してIssueコンテキストを得ることで、詳細を知るためにフローを中断する必要がなくなりました。
Issueホバーは、完全なIssue URL、IssueコメントURL、番号で参照されるIssue (#1234)、およびowner/repository#1234で参照されるIssue (例: Microsoft/vscode#1234) で機能します。また、私たちのコードベースではユーザーを参照することもよくあります。VS Codeの提案されたAPIには、提案の責任者が誰であるかを明確にするための多くの開発者参照があります。
Issueコンテキストは通常、コミットが解決するIssueを参照するためのコミットメッセージ内、ソースコードファイル内、およびMarkdown内（変更履歴など）で必要とされます。このコンテキストを簡単に追加するために、Issueとユーザーの補完候補を追加しました。Gitコミットテキストボックスでは、githubIssues.issueCompletionFormatScm設定を使用してIssue補完をフォーマットできます。Markdownファイルでは、IssueはMarkdownリンクとして補完され、他のファイルでは、Issueは単純なIssue番号 (#1234) として補完されます。
可能なIssueのリストはgithubIssues.queries設定で設定可能なので、複数のリポジトリで作業している場合は、それらのIssueのクエリを含めることができます。クエリはGitHub検索構文を使用します。ユーザーのリストには、現在開いているリポジトリのコラボレーターが含まれます。
どこからでもIssueを作成
ソースコードを操作中にVS Codeでバグを見つけた場合、私たちはIssueを作成し、その領域の担当者に割り当てます。または、バグの発見者が担当者でもある場合、後で戻るためのリマインダーとして//TODOコメントを残すことがよくあります。コードベース全体に//TODOが散らばっていると、多くのコントリビューターがいる場合、追跡が難しくなります（誰もが経験したことがあるでしょうが）。しかし、Issueを作成して//TODOで参照することで、追跡可能になります。ソースの奥深くで作業中にIssueを作成する際の障壁とコンテキストの喪失を減らすために、Issueを作成するいくつかの新しい方法があります。
//TODOコメントから (githubIssues.createIssueTriggersで設定可能)、VS Codeを離れることなくIssueを作成および割り当てることができます。
また、選択範囲から、GitHub Issues: Create Issue from Selectionコマンドを使用して、発生元のソースコードへのパーマリンク付きのIssueをすばやく作成できます。単にコードへのポインタが必要な場合は、GitHub Issues: Copy GitHub Permalinkコマンドも使用できます。最後に、ターミナルにエラー情報がある場合は、出力をクリップボードにコピーして、GitHub Issues: Create Issue from Clipboardを使用してIssueを作成できます。
Issueの作業
一般的なワークフローは、Issuesを見て、作業するものを選択し、作業用のブランチを作成し、いくつかのコミットを行い、プルリクエストで変更をメインにマージするというものです。新しいIssuesビューから、まさにそれを行うことができます。
より多くのワークフローに対応するために、いくつかのオプションを設定できます。フローにトピックブランチの作成が含まれない場合は、githubIssues.useBranchForIssuesでブランチ作成を無効にできます。ブランチに異なる命名規則がある場合は、githubIssues.issueBranchTitle設定を使用できます。Issuesビューに表示されるIssueは、githubIssues.queriesでカスタムクエリを使用するように設定できます。
もっと詳しく知りたいですか？
GitHub Satelliteで行われたSana Ajani (@sana_ajani) とBurke Holland (@burkeholland) による「What every GitHub user should know about VS Code」という講演を視聴できます。
また、VS CodeのGitHub連携をより詳細に説明しているGitHubの操作トピックも読むことができます。
今後の展望
現在、これらの機能のほとんどはリポジトリのクローン（フォークではない）でのみサポートされているため、それらや他のユースケースをサポートするためには、さらに作業が必要です。この拡張機能に関する皆様からのフィードバックをお待ちしておりますので、拡張機能のリポジトリのIssuesに提案を残していただければ幸いです。
ハッピーコーディング！
Alex Ross, VS Code開発者 @alexr00