GitHub Issues連携のご紹介
2020年5月6日 Alex Ross, @alexr00 著
Visual Studio Codeチームでは、GitHub issues を使用してすべての作業を追跡しています。詳細な イテレーション計画 から個々のバグまで、すべてをGitHub issueとして追跡しています。Issueが私たちのチームや他のGitHubプロジェクトにとってどれほど重要であるかを考えると、VS CodeにGitHub issues連携を追加したいと考えました。この追加は、1年以上前に 発表 したGitHubプルリクエストの作業を補完するものです。VS Codeバージョン1.45以降では、issueとソースコードをより密接に結び付けるこの新しいサポートが、GitHub Pull Requests and Issues 拡張機能(以前はGitHub Pull Requestsという名前でした)で利用できるようになります。
私たちの統合アプローチ
Issueとプルリクエストはしばしば密接に関連しているため、同じ GitHub Pull Requests and Issues 拡張機能に含めることは論理的なステップでした。なぜなら、同じ GitHub API がissueとプルリクエストの両方に必要となることが多いためです。多くのソース管理オプションがあるため、GitHub機能をVS Codeエディターのコアに直接追加したくありませんでした。代わりに、ユーザーが開いているリポジトリがGitHubを使用していることを検出した場合に、拡張機能をお勧めします。独自の 拡張機能API を使用することで、APIが拡張機能の作成者に必要な機能を備えていることを保証し、他のリポジトリプロバイダーも同様の統合を実装できます。
過度に具体的なワークフローを規定しないことが重要でした。代わりに、私たちの目標は、柔軟な方法でissueをインナー開発ループに取り込むことでした。たとえば、コードコメントでissueに関するより多くのコンテキストを提供することはその目標の一部ですが、完全なissue管理をVS Codeに追加することはあまり適切ではありません。GitHubがすでにうまく行っているUIを再発明したくはありません。私たちは、まだ存在しないつながりを作りたいのです。
コードコンテキストにおけるIssue
ソースコード内のissueへのリンクは、特に理解が難しいロジックがある場合や、対応が必要な //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(changelogなど)で必要になります。このコンテキストを簡単に追加するために、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への取り組み
一般的なワークフローは、issueを確認し、取り組むissueを選択し、作業するブランチを作成し、いくつかのコミットを行い、プルリクエストで変更をメインにマージすることです。新しい Issues ビューから、まさにそれを実行できます。
より多くのワークフローに適合させるために、構成できるいくつかのオプションがあります。フローにトピックブランチの作成が含まれていない場合は、githubIssues.useBranchForIssues
でブランチ作成を無効にできます。ブランチの命名規則が異なる場合は、githubIssues.issueBranchTitle
設定を使用できます。Issues ビューにリストされるissueは、githubIssues.queries
でカスタムクエリを使用するように構成できます。
さらに詳しく知りたいですか?
GitHub Satellite のSana Ajani (@sana_ajani) とBurke Holland (@burkeholland) による すべてのGitHubユーザーが知っておくべきVS Code に関する講演をご覧ください。
また、VS CodeのGitHub連携についてより詳細に説明している GitHubの操作 トピックをお読みください。
今後の展望
現在、これらの機能のほとんどはリポジトリクローン(フォークではない)でのみサポートされているため、それをサポートするため、およびその他のユースケースをサポートするためには、さらに多くの作業を行う必要があります。この拡張機能に関するフィードバックをお待ちしておりますので、拡張機能 リポジトリ のissueでお気軽に提案をお寄せください!
Happy Coding!
Alex Ross, VS Code開発者 @alexr00