GitHub Foundations #3 Domain 2: リポジトリの扱い — ブランチ・タグ・リリース・gist

Domain 2はGitHubでの作業の基本単位であるリポジトリ（repository） を扱います。作成し、構成ファイルを整え、複製し、公開範囲を決め、寿命を管理する全過程が範囲です。概念自体は難しくありませんが、似て見える機能の区別（forkとclone、タグとリリース）を正確に問うため、この記事はその境界を中心に整理します。

リポジトリの作成と初期化オプション #

WebのNew repositoryでリポジトリを作るときに決めるのは3つです。名前と説明、可視性（公開範囲）、そして初期化オプションです。初期化オプション3つは、それぞれファイルをひとつ最初のコミットに入れてくれます。

• README — リポジトリの最初の画面にレンダリングされる紹介文書です。
• .gitignore — 言語別テンプレート（Python、Nodeなど）から選んで、追跡除外ルールをあらかじめ敷いてくれます。
• LICENSE — コードの使用条件を示すライセンスファイルです。公開リポジトリでライセンスがないと、法的には他人が使えないコードになるという点が出題されることもあります。

コミュニティファイル — 決まった名前の特別なファイル #

GitHubは決まった名前のファイルを特別に扱います。試験では「この情報はどこに置くか」という形で問われます。

個人アカウント名と同じ名前のリポジトリにREADMEを置くとプロフィールページに表示されるプロフィールREADMEの機能も、Domain 2で言及される項目です。

default branch — リポジトリの基準ブランチ #

リポジトリには基準となるブランチがひとつあります。新しくcloneするとチェックアウトされるブランチであり、PRを開くときのデフォルトのbaseになるブランチです。現在のデフォルト名はmainで、リポジトリ設定から別のブランチに変更できます。ブランチに強制ルールをかける保護機能はDomain 6で扱うので、ここでは名前と役割だけ押さえておけば大丈夫です。

タグとリリース — 同じ地点、異なる層 #

Domain 2を代表する区別です。

• タグ（tag） — 特定のコミットに付ける名札で、Gitの機能です。v1.2.0のようにバージョンを示すために使われます。
• リリース（release） — タグをもとに、リリースノートとビルド成果物（アセット）を一緒に配布するGitHubの機能です。ダウンロードページが作られ、ソースコードのアーカイブが自動的に添付されます。

つまり、リリースはタグなしには存在できず（作成時に新しいタグを作ることもできます）、タグはリリースなしでも存在します。「バイナリファイルをユーザーに配布するには何を使うか？」という問題の答えはリリースです。

gist — リポジトリより軽いコード片の共有 #

ファイル数個のコード片を共有するときは、リポジトリの代わりにgistを使います。2種類あります。

• public gist — 検索と発見ページに露出します。
• secret gist — 検索には露出しませんが、URLを知っている人は誰でも見られます。 非公開リポジトリのようなアクセス制御ではないという点が出題ポイントです。

gistも内部的にはGitリポジトリなので、cloneしてバージョン管理ができます。

fork、clone、テンプレートリポジトリ — 3つの複製の違い #

Domain 2で最も頻繁に出る区別です。3つとも「リポジトリを複製する」ように見えますが、方向とつながりが異なります。

シナリオ型の問題として出題されます。「書き込み権限のないプロジェクトに修正を提案するには？」はforkしてPR、「チーム標準の構造で新プロジェクトを始めるには？」はテンプレートリポジトリです。forkはサーバーからサーバーへの複製なので、forkだけでは自分のコンピュータに何も落ちてこないこと、作業するにはfork先を改めてcloneする必要があることも合わせて覚えておいてください。

リポジトリの可視性 — public、private、internal #

• public — インターネットの誰でも読めます。書き込みは別の権限です。
• private — 招待されたコラボレーターと権限を付与されたチームだけがアクセスします。
• internal — Enterprise専用で、同じ企業のメンバー全体にだけ見えます。組織内部の共有（InnerSource）に使われます。

「企業のメンバー全員には開き、外部には閉じる」というシナリオが出たらinternalです。Enterpriseプランでのみ可能という条件までがひとまとまりの出題ポイントです。

トピック、スター、ウォッチ — リポジトリの発見と購読 #

リポジトリを見つけて追いかける機能もDomain 2の範囲です。3つの機能の役割の区別が出題ポイントです。

• トピック（topic） — リポジトリに付ける分類キーワードです。machine-learning、hugoのように主題を宣言しておくと、トピック検索でリポジトリが発見されます。タグ（コミットの名札）と名前が似ていますが、まったく別の機能です。
• スター（star） — 関心の表明でありブックマークです。スター一覧から再び見つけられ、リポジトリのスター数は知名度の指標として読まれます。スターを押しても通知は届きません。
• ウォッチ（watch） — 通知の購読です。ウォッチしたリポジトリのIssue、PR、リリースの活動が通知として届きます。全活動、リリースのみ、メンションのみのように購読範囲を選べます。

「リポジトリの新しいリリースの知らせだけ受け取りたい」というシナリオの答えは、スターではなくウォッチ（リリースのみ）です。スターは覚えておくための機能、ウォッチは通知を受け取るための機能という1行の区別で十分です。

アーカイブ、削除、移管 — リポジトリの寿命管理 #

• アーカイブ（archive） — リポジトリを読み取り専用に切り替えます。Issue、PR、pushがすべてロックされ、最初の画面にアーカイブの案内が表示されます。メンテナンスが終わったプロジェクトを消さずに保存する方法で、いつでも解除できます。
• 削除（delete） — リポジトリを取り除きます。削除直後の一定期間は復元できますが、基本的には取り消せない操作とみなし、保存が目的ならアーカイブを使うのが正解の方向です。
• 移管（transfer） — リポジトリの所有権を別のアカウントやOrganizationへ移します。移した後も、旧URLへのアクセスは新しい場所へリダイレクトされます。

まとめ #

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

• リポジトリはREADME、LICENSE、CONTRIBUTINGのような決まった名前のコミュニティファイルで案内体系を整え、.github/ディレクトリにテンプレートと設定を置きます。
• タグはコミットの名札（Git）、リリースは配布ページ（GitHub）で、fork・clone・テンプレートは複製の方向と元とのつながりで区別します。
• 可視性はpublic、private、internalの3段階で、internalはEnterprise専用です。

次回の「GitHub Foundations #4 Domain 3-1: コラボレーション — Issue・ラベル・マイルストーン・テンプレート」からは、試験で比重が最も大きいコラボレーション機能に入ります。Issueを中心にした作業管理の機能から整理します。