GitHub を利用し、リポジトリ履歴を検索し、整理する方法
ここでは、フィルター、blame、クロスリンクを使用してリポジトリ履歴を検索し、整理する方法について説明します。
あなたは大規模なプロジェクトに参加したばかりの開発者です。 Web アプリのサイド バーに関連するバグを報告する新しいイシューを誰かが投稿しました。そして、それを解消する役目があなたに与えられました。 レポートは既に数回読んでおり、説明されている問題を理解しています。これからすべきことは、修正を開始する方法を決定することです。
チームの新しいメンバーであるあなたは、コードベースにまだ慣れていません。 また、実装を開始するのに必要なコンテキストを提供してくれる、計画のディスカッション、コード レビューなどにも参加していません。 最初に必要なことは、正しい修正プログラムを最適に判断するための背景知識を得ることです。
GitHub の検索
サイド バーの実装につながったイベントには参加していなくても、そのようなイベントの多くは、プロジェクトの履歴に残っています。 プロジェクトのリポジトリを "sidebar" を検索すると、取り付く手掛かりがわかります。
GitHub では 2 つの検索手法を利用できます。ページの一番上にあるグローバル検索と、特定のリポジトリ タブで利用できる範囲指定検索です。 同じ構文と同じ関数が同じ方法でサポートされていますが、大きな違いがいくつかあります。
グローバル検索
グローバル検索では、完全な検索構文を使用し、GitHub 全体を検索できます。
検索結果は包括的なものであり、コード、イシュー、マーケットプレース、さらにはユーザーまで、あらゆるものが含まれています。 結果の種類やリポジトリが複数のとき、それら全体で主要用語の言及を見つける方法としてはこれが最良です。
注意
フィルター句 is:pr では、issues/pull requests ストアから返されたイシューが除外されます。 is:pr など、一部のフィルター句は、特定の検索プロバイダーでのみサポートされ、他の検索プロバイダーの場合は無視されます。 たとえば、コード検索プロバイダーではこの句はサポートされません。そのため、句は無視され、句がないときと同じコード結果が返されます。
今回のシナリオでは、現在のリポジトリに範囲を指定したグローバル検索を使用することは、"sidebar" という用語が含まれるコードやコミットを検索する方法としてお勧めです。 イシューや pull request でヒットする可能性もありますが、グローバル検索結果の表示ではそれらをさらにフィルター処理することは簡単ではありません。
複雑なグローバル検索を作成するには、高度な検索をお試しください。
コンテキスト検索
コンテキスト検索は、[イシュー] や [pull request] など、特定のタブで利用できます。 これらの検索の範囲には現在のリポジトリが指定され、その種類の結果のみが返されます。 この範囲指定の利点は、[Author]、[Label]、[Projects] など、既知の、種類固有のフィルターをユーザー インターフェイスに表示できることです。
現在のリポジトリで何かを探しているときは、コンテキスト検索の使用が望ましい選択肢です。 このシナリオでは、これは "sidebar" に言及している検索結果を見つける方法としてお勧めです。それから、フィルター ドロップダウンを使用して簡単に絞り込むことができます。
検索フィルターの使用
完全な検索構文を使用して検索する方法は無限に存在します。 ただし、ほとんどの検索では、2、3 の共通フィルターが使用されるだけです。 共通フィルターは多くの場合、コンテキスト検索ドロップダウンから利用できますが、直接入力した方が便利なときもあります。
フィルター クエリの例を次に示します。
| クエリ | 説明 |
|---|---|
is:open is:issue assignee:@me |
現在のユーザー (@me) に割り当てられている未処理のイシュー |
is:closed is:pr author:contoso |
@contoso によって作成された処理済みの pull request |
is:pr sidebar in:comments |
コメントに "sidebar" の言及がある pull request |
is:open is:issue label:bug -linked:pr |
pull request がリンクされていないバグのラベルが付いている未処理のイシュー |
詳細については、「検索構文を理解する」をご覧ください。
git blame とは何か
その険悪な名前とはうらはらに、git blame は、あるファイルのコミット履歴を表示するコマンドです。 誰がいつどのような変更を行ったのか、簡単に確認できます。 他のユーザーの入力や関与を見つけ出すために、ファイルに対するユーザーの作業を追跡することがとても簡単になります。
注意
非難の意味を避ける目的で、一部の Git システムでは、git blame に git praise という別名が付きます。
GitHub の Blame
GitHub では、もっと堅牢なユーザー インターフェイスを利用し、基本の git blame 機能が拡張されます。
今回のシナリオでは、何とおりかの方法でこの表示に移動できます。 グローバル検索から何かのサイド バーのコードを見つけて、[Blame] オプションを選択し、最後にそのコードに対して作業したユーザーを確認したり、pull request を見つけて、そのバグの説明に関連していると思われる最後のコミットを追跡したかもしれません。 この表示にたどり着いた方法に関係なく、blame ビューは、手元にある仕事の専門家を見つける上で効果があります。
イシュー、コミット、その他をクロスリンクする
共同作業ソフトウェア プロジェクトとして GitHub が優れている理由の 1 つに、共通点のない情報をリンクできることがあります。 ブランチで一連のコミットから pull request を作成するときなど、クロスリンクの一部は自動的に行われます。 その他の場合、インターフェイスとドロップダウン オプションを利用し、pull request やプロジェクトをイシューに手動でリンクできます。
参照の自動リンク
プロジェクト全体でさまざまな項目をクロスリンクすることをもっと簡単にする目的で、GitHub には短縮構文があります。 たとえば、Duplicate of #8 のようなコメントを残すと、GitHub では #8 がイシューであることが認識され、適切なリンクが自動的に作成されます。
GitHub ではまた、その ID の最初の 7 文字以上を貼り付けると、コミットが自動的にリンクされます。
今回のシナリオでは、コンテキストを残すことを誰かが前もって考えていた場合、こうしたリンクは、強化のために非常に有効であると証明されるでしょう。 たとえば、このサイド バーの現在の状態では、JavaScript の依存関係に関連する、いくつかの既知の issue が含まれている場合があります。 その依存関係の issue が、"sidebar" についてはっきり言及していなかった別の issue 内で議論されていた場合、それを見つけることは難しくなるでしょう。 しかしながら、ディスカッションでそのイシューをリンクすることを前もって考えていた場合、ここで時間が大幅に節約されるでしょう。 次回、イシューと pull request を記録するとき、この点にご留意ください。
詳細については「自動リンクされた参照と URL」をご覧ください。
@mention で輪になるユーザー
イシューとコミットをリンクする以外に、他のユーザーとディスカッションを関連付けることも役立つことがあります。 これを行う最も簡単な方法は @mention を使用することです。 この種類のメンションでは、ディスカッションに参加できるよう、言及されたユーザーに通知されます。 処理後もずっと、イシューに関連付けられているユーザーを特定することも良い方法です。
