GitHub Foundations #9 Domain 7: GitHubコミュニティ + 試験のコツ

ツール Git GitHub Certification
読了 7分

最後のドメインであるBenefits of the GitHub Communityは分量が大きくなく、問われ方も大半は定義をそのまま確認する形です。概念の名前と1行の定義さえ正確につないでおけば、素早く得点して通過できる領域です。ドメインの整理を終えたあとは、シリーズの慣例どおり、試験直前に確認するコツをまとめました。

オープンソースとソース公開は違います #

試験が最も好む区別から始めます。リポジトリをpublicにすることとオープンソースは同じではありません。

  • ソース公開（source available） — コードを誰でも見られる状態です。見ることと使うことは別なので、ライセンスがなければ、法的には使用・改変・再配布の権利は付与されません。
  • オープンソース（open source） — コードの公開に加えて、使用・改変・再配布を許可するライセンスが付与された状態です。MIT、Apache 2.0、GPLといったライセンスファイルがその権利の根拠です。

だからこそ「publicリポジトリだがLICENSEファイルがないプロジェクト」はオープンソースではない、という引っかけの選択肢が成立します。ライセンスごとの違い（許容型とコピーレフトの区別など）はFoundationsレベルでは深入りしないので、ライセンスが権利を定義するという原則まで正確に押さえておけば十分です。

コミュニティファイル — プロジェクトの標準セット #

健全なオープンソースプロジェクトが備える標準ファイルです。各ファイルの役割をマッチングさせる問題が出ます。

ファイル役割
READMEプロジェクトの紹介、インストールと使い方の入り口
LICENSE使用・改変・再配布の権利の法的根拠
CONTRIBUTING貢献の手順とルール（ブランチ、PR、コーディング規約）
CODE_OF_CONDUCTコミュニティの行動規範
SUPPORT質問やサポートを求める窓口の案内
SECURITY脆弱性の報告手順（Domain 6とつながる）

これらのファイルが揃っているかを一目で確認する画面が、前回扱ったリポジトリInsightsのCommunity Standardsチェックリストです。.githubリポジトリを作っておくと、組織の複数リポジトリがこれらのファイルを共通で継承できるという点もあわせて覚えておく価値があります。

InnerSource — オープンソースのやり方を組織の中へ #

InnerSourceは、オープンソースのコラボレーション方式を組織内部のprivateリポジトリに適用することです。コードは社外に公開しませんが、組織の中では他チームのリポジトリを閲覧し、Issueを開き、PRで貢献するオープンソース式の流れに従います。

  • オープンソースとの違いは公開範囲です。オープンソースの対象が全世界なら、InnerSourceの対象は組織の内部です。
  • 効果はサイロの解消です。チーム間の重複開発が減り、よくできた社内ライブラリに組織全体の貢献が集まります。

定義として問われても、シナリオ（「社内のコードベースにオープンソース式の貢献文化を導入したい」）として問われても、答えがInnerSourceに収束する、Domain 7の代表的な出題ポイントです。

後援・拡張・学習 — 残りのコミュニティ機能 #

名前と用途をつないでおくだけでよい項目です。

  • GitHub Sponsors — オープンソースの開発者とプロジェクトを金銭的に支援する機能です。
  • GitHub Marketplace — Actionsやアプリのような拡張ツールを探してインストールするマーケットです。
  • GitHub Community — ユーザーが質問し議論する公式フォーラムです。
  • GitHub Skills — 実習リポジトリベースの無料学習コース集で、この試験の公式準備資料でもあります。

オープンソース貢献の標準サイクル #

コミュニティのドメインは、貢献の手順をシナリオとして問うこともあります。他の人の公開リポジトリに貢献する標準の流れは次の順です。

  1. リポジトリを自分のアカウントにforkします。オリジナルへのpush権限がないので、サーバー側の複製が必要です。
  2. forkをcloneしてブランチを作り、変更をコミットします。
  3. forkにpushしたあと、オリジナルのリポジトリに向けてPRを開きます。forkのブランチがcompare、オリジナルのブランチがbaseになります。
  4. レビューを反映し、マージはオリジナルのリポジトリの管理者が決めます。

CONTRIBUTINGファイルがこの手順のプロジェクトごとのルール（ブランチ名、コミット規約、テスト要件）を定義するので、貢献の前に最初に読むべきファイルを問われたら、答えはCONTRIBUTINGです。

プロフィールと発見の機能 #

  • プロフィールREADME — アカウント名と同じ名前のリポジトリにREADMEを置くと、プロフィール上部に自己紹介として表示されます。
  • スター（star） — リポジトリをブックマークする機能で、スター数はプロジェクトの認知度を測るシグナルとして使われます。
  • フォローとトレンド — 他のユーザーの活動をフィードで受け取り、Exploreとトレンドで注目のリポジトリを発見します。

ここまでが7つのドメインの最後のピースです。あとは試験会場に向かう前に確認することを整理します。

試験のコツ — 問題タイプ別のアプローチ #

Foundationsの問題は大きく3タイプに分かれます。

  • 定義マッチング型 — 「組織の内部にオープンソース方式を適用するのは?」のような直接確認の問題です。このシリーズの表を裏返した形なので、各表を双方向（名前→定義、定義→名前）に読んでおけば対応できます。
  • 機能の境界型 — 似た2つの機能からシナリオに合う方を選ぶ問題です。プランの違い、リポジトリrole、Dependabotの3機能のように、境界のある場所がすべて候補です。
  • UIの位置型 — 「この情報はどこで確認するか」を問う問題です。Insightsのタブ構成、設定画面の位置を思い浮かべられる必要があります。

間違えやすいパターン #

  • fork vs clone — forkはGitHubアカウントに作るサーバー側の複製で、cloneは自分のコンピュータに受け取るローカルの複製です。「他の人の公開リポジトリに貢献するには」の最初のステップはforkです。
  • Issue vs Discussion — Issueは追跡して閉じるべき作業・バグで、Discussionは結論が開かれた質問・アイデアの対話です。
  • github.dev vs Codespaces — github.devはブラウザのエディタにすぎずコードの実行環境がなく、Codespacesはクラウドで動く完全な開発環境です。「ターミナルでビルドまでするなら」の答えはCodespacesです。
  • Write vs Maintain vs Admin — pushとマージはWriteから、リポジトリ設定はMaintainから、セキュリティ設定と削除はAdmin専用です。
  • Git vs GitHub — Gitはローカルで動くバージョン管理ツールで、GitHubはその上にコラボレーション機能を載せたホスティングサービスです。PRのようなGitHub側の機能をGitコマンドと錯覚させる選択肢をふるい落とします。

時間管理と受験環境 #

  • 120分で75問前後なので、1問あたり90秒以上の余裕があります。詰まる問題はフラグを付けて先に進み、最後に見直す方が全体の得点に有利です。
  • オンライン監督（PSI）での受験なら、身分証、Webカメラ、画面共有ができる静かな場所を事前に点検し、試験プログラムのシステムチェックを前日に回しておきます。机の上の持ち物制限のような規定も事前案内に従います。
  • 合格基準とドメインの比重は変わる可能性があるので、受験の直前に公式study guideの最新版を一度確認するのが安全です。
ヒント
試験前日の確認リストは3つで十分です。リポジトリrole 5段階の表、Dependabot 3機能の区別、そして上の間違えやすいパターン5つです。残りは問題の中に手がかりが一緒に出てくることが多いです。

まとめ #

この記事の要点は3つです。

  • オープンソースは公開されたコードではなく、ライセンスで使用・改変・再配布の権利が付与されたコードであり、InnerSourceはそのコラボレーション方式を組織内部に適用したものです。
  • Sponsors、Marketplace、Skillsといったコミュニティ機能は、名前と用途の1対1マッチングで出題されます。
  • 問題タイプは定義マッチング、機能の境界、UIの位置の3つに収束し、境界のある表を双方向に読んでおくことが最善の準備です。

次回の「GitHub Foundations #10 ボーナス — フルスケール択一模擬試験」がシリーズの最後です。7つのドメイン全体を、実際の試験と同じ形式の50問で点検し、各問に解説を付けました。

X