GitHub Foundations #2 Domain 1: GitとGitHub入門 — バージョン管理と製品構造
Domain 1は試験全体の土台です。ここで固める2つの区別、つまりGitとGitHubの境界とアカウント・プランの構造が、以降のすべてのドメインの前提になります。Gitコマンド自体は当ブログのGit基礎 #1から続くシリーズで手を動かして身につけるのが王道なので、この記事は試験が問うポイントだけを絞って整理します。
試験が問うGit — 要点だけもう一度 #
バージョン管理システムは、ファイルの変更履歴を記録し、過去の時点に戻り、複数人の修正を安全に統合するためのツールです。Gitについて試験では、深い内部構造よりも次のレベルの理解を確認します。
- Gitは分散バージョン管理システムです。リポジトリ全体（履歴を含む）が各自のコンピュータに存在し、ネットワークなしでコミットと照会ができます。
- コミットは差分ではなく、その時点のプロジェクト全体のスナップショットです。
- ファイルはworking directory、staging area、repositoryの3つの領域を通って記録されます。
基本コマンドは役割を1行で答えられれば十分です。
| コマンド | 役割 |
|---|---|
git init | 現在のディレクトリをリポジトリとして初期化 |
git clone | リモートリポジトリを履歴ごと複製 |
git status | 3つの領域の現在の状態を要約 |
git add | 次のコミットに入れる変更をstaging areaへ |
git commit | staging areaの内容でスナップショットを記録 |
git branch / git switch | ブランチ一覧の確認 / ブランチの切り替え |
git merge | 別ブランチの変更を現在のブランチに統合 |
git push / git pull | リモートへ送る / リモートから取得して統合 |
この表に馴染みがなければ、Git基礎シリーズを先に終えてから戻ることをおすすめします。Domain 1のGit問題はそのシリーズの範囲とほぼ重なります。
GitとGitHubは別物です #
Domain 1で最も頻繁に出題される区別です。2つを混ぜて使う癖があるなら、試験前に境界をはっきりさせておく必要があります。
- Git — 自分のコンピュータで動くバージョン管理ツールです。オープンソースであり、特定企業のサービスではありません。コミット、ブランチ、マージはすべてGitの領域です。
- GitHub — Gitリポジトリを置くクラウドのホスティングプラットフォームであり、その上にコラボレーション機能（Issue、Pull Request、レビュー、Actions）を載せたサービスです。
したがって「GitHubなしでGitは使えるか？」という質問の答えは「使える」です。逆にGitHubのPull RequestはGitコマンドではなくプラットフォーム機能なので、git pull-requestのようなコマンドは存在しません。同じ層の代替プラットフォームとしてGitLabとBitbucketがあることも知っておくとよいです。
アカウント構造 — 個人、Organization、Enterprise #
GitHubのアカウントは3つの層で構成されます。
- 個人アカウント（personal account） — 人ひとりのアカウントです。個人所有のリポジトリを作り、他のリポジトリにコラボレーター（collaborator）として招待されます。
- Organization — 人ではなく、複数人が共有する所有主体です。リポジトリを組織名義で所有し、メンバーをチーム（team）にまとめて、リポジトリごとの権限をチーム単位で付与します。会社やオープンソースプロジェクトが使う形態です。
- Enterpriseアカウント — 複数のOrganizationを束ね、ポリシー（認証方式、ポリシーの強制、請求）を一か所で管理する最上位の単位です。
試験では「複数チームでリポジトリ権限を共有する必要がある」というシナリオにOrganizationを、「複数のOrganizationのポリシーを統合管理する」というシナリオにEnterpriseを選ぶ形で出題されます。
プラン — Free、Team、Enterprise #
機能の境界を問う問題がよく出る領域です。全体像は次のとおりです。
| プラン | 中心 |
|---|---|
| Free | 公開・非公開リポジトリ無制限、基本のコラボレーション機能、ActionsとCodespacesの無料使用枠 |
| Team | Freeの全部 + 非公開リポジトリでの保護ブランチ、code ownersなどの高度なコラボレーション機能、より大きい使用枠 |
| Enterprise | Teamの全部 + SAML SSOのような企業向け認証、internalリポジトリ、監査ログの強化、GitHub Advanced Securityアドオン |
よく出題される境界は2つです。
- 保護ブランチ（branch protection）は公開リポジトリならFreeでも使えますが、非公開リポジトリではTeam以上が必要です。「Freeプランのprivateリポジトリでできないもの」を選ぶ問題の定番です。
- internalリポジトリの可視性とSAML SSOはEnterprise専用です。 組織規模のシナリオが出たらEnterpriseを思い浮かべれば大丈夫です。
GitHub Flavored Markdown — プラットフォーム全体の文書言語 #
Domain 1にはマークダウンの基礎も含まれます。README、Issue、PRの説明、コメントまで、GitHubのすべてのテキスト入力がGitHub Flavored Markdown（GFM） としてレンダリングされるからです。試験は文法を見て結果を選ぶ、またはその逆を選ぶレベルで出題されます。
# 見出し1 ## 見出し2
**太字** *斜体*
- 順序なしリスト
1. 順序ありリスト
[リンクテキスト](https://example.com)
`インラインコード`
- [ ] タスクリスト（チェックボックス）標準マークダウンにGitHubが加えた拡張が、それ自体で出題ポイントになります。
- タスクリスト —
- [ ]と- [x]でチェックボックスを作り、IssueとPRでは画面から直接トグルできます。 - メンション —
@ユーザー名を書くとそのユーザーに通知が届きます。チームメンション（@組織/チーム名）もできます。 - 参照 —
#123のように番号を書くと、そのIssueやPRへのリンクになります。コミットハッシュでも同じ方式でリンクされます。 - コードフェンスの言語指定 — バッククォート3つの後に言語名を書くとシンタックスハイライトが適用されます。
GitHubにアクセスする4つの方法 #
同じGitHubを使う経路が複数あるという点もDomain 1の範囲です。
- Webブラウザ — 基本の経路です。コラボレーション機能（Issue、PR、レビュー）の大半はWebで行われます。
- GitHub Desktop — 公式のGUIクライアントです。ターミナルなしでコミットとpushを処理でき、非開発職に有用です。
- gh CLI — 公式のコマンドラインツールです。
gh pr create、gh issue listのように、GitHubのプラットフォーム機能をターミナルから操作します。Gitコマンドを置き換えるのではなく補完するという点が出題ポイントです。 - GitHub Mobile — 通知の確認、レビューの承認、Issueへの返信といった移動中の作業向けの公式アプリです。
エディタ統合（VS CodeのGitHub拡張など）まで含めて、「ターミナルがなくてもGitHubは使えるか？」という問いに「使える」と答えられれば、この節は十分です。
まとめ #
この記事の要点は3つです。
- Gitはローカルで動く分散バージョン管理ツールで、GitHubはそのリポジトリをホスティングしてコラボレーション機能を載せたプラットフォームです。この境界がDomain 1の中心です。
- アカウントは個人、Organization、Enterpriseの3層で、共有所有とチーム権限が必要ならOrganizationです。
- プランの問題は2つの境界、つまり非公開リポジトリの保護ブランチはTeamから、internalリポジトリとSSOはEnterpriseからを覚えれば大半が解決します。
- GFMはプラットフォーム全体の文書言語で、タスクリスト、メンション、
#番号参照といったGitHub拡張が出題ポイントです。
次回の「GitHub Foundations #3 Domain 2: リポジトリの扱い — ブランチ・タグ・リリース・gist」では、リポジトリ単位の機能を整理します。forkとcloneとテンプレートリポジトリの違いのような、Domain 2の定番の区別が続きます。