公開プロジェクトと主張を選ぶ
自分のプロジェクト、または調査対象の組織の具体的な公開リポジトリから始めます。その完全なowner名とrepository名をコピーします。見つけたい機能の説明文を正確に書き出し、ドキュメントと実装のテストを区別します。
この手順はプロジェクトのドキュメントを見つけるためのものです。露出した認証情報、非公開の連絡先情報、リポジトリのアクセス制御を回避する方法を検索しないでください。
コード検索の修飾子を意図的に使う
GitHubのコード検索ドキュメントは、単独の語がファイルパスにもその内容にも一致しうると説明しています。repo:は検索を完全なowner/repository名に限定し、path:はパスを絞り込み、content:は語がファイル本文に含まれることを要求します。引用符で囲んだ文字列は正確な文言を検索できます。これらのルールはコード検索に適用され、issuesやプロフィール検索に自動的に当てはまるわけではありません。出典
例としてexample-owner/example-projectというリポジトリの場合、クエリは次のようになります。
repo:example-owner/example-project content:"export format"名前とフレーズはプレースホルダーであり、実際に実行した検索ではありません。レビューする権限があるリポジトリと、自分の問いに関連する文言に置き換えてください。ファイルがドキュメント用パスの下にあると分かっている場合は、適切なpath:制限を追加します。そうでなければ、その前提は省きます。
引用する前に一致を解釈する
| 結果 | 確認すべきこと | 証明しないこと |
|---|---|---|
| ファイル名の一致 | フレーズが本文に含まれるか | そのファイルが説明文を裏付けること |
| ドキュメントの一節 | 近くにあるバージョンや機能の条件 | 記述された機能がテストされたこと |
| 例や提案 | 計画中または例示的な動作を述べているか | その機能がリリース済みであること |
| 結果なし | リポジトリ、クエリの種類、制限 | その主張がどこにも存在しなかったこと |
GitHubは、すべての公開リポジトリを対象とするコード検索にサインインが必要であると文書化しています。また、GitHub Pagesのウェブサイトとリポジトリのソースコンテンツを区別しています。出典 実際の検索対象とアクセス制限を記録してください。サインインの制限を回避したり、検索していないウェブサイトを対象に含めたと扱ったりしないでください。
一節をバージョンに結びつけておく
ファイルを開き、関連する完全なセクションを読みます。文書化された主張はプロジェクトに帰属させます。この読解作業を完了するためだけにリポジトリのコードを実行しないでください。また、スター数やアカウント名から製品の信頼性を推測しないでください。
正しい一節が見つかったら、GitHubパーマリンクガイドに従って、確認したバージョンを保持します。次にAI情報源レビューチェックリストが、その文書の記述とモデルが付け加えた結論を切り分けるのに役立ちます。