GitHubの画面を開くと、ファイルの一覧やREADME、さまざまなタブが並んでいます。初めて見ると、どこから読めばよいのか迷うかもしれません。
最初に押さえたいのは、GitHubはプロジェクトを共有するサービス、リポジトリはファイルと変更履歴を管理する単位、READMEはそのプロジェクトを理解するための案内文という関係です。この3つがつながると、画面の見方も、自分の成果物の整理方法もわかりやすくなります。
この記事では、プログラミングに詳しくない人を想定し、用語の関係からREADMEの書き方まで説明します。掲載したフォルダ構成とREADMEは、説明用に作成した例です。
1. GitHubは、プロジェクトを共有して進める場所
GitHubは、Gitで管理するプロジェクトをインターネット上に置き、他の人と共有したり、変更について話し合ったりできるサービスです。Gitはファイルの変更履歴を管理する仕組みで、GitHubはそれを使った共同作業の場を提供します。GitHub公式:GitHubとは
たとえば、チームで小さなWebサイトを作る場合、画面のファイル、説明資料、修正の相談を一か所にまとめられます。GitHubのリポジトリでは、Issueで課題を整理し、Pull Requestで変更を提案することもできます。GitHub公式:リポジトリについて
ただし、最初からすべての機能を使う必要はありません。まずは「何を作っているのか」「ファイルはどこにあるのか」「使い方はどこに書かれているのか」を読めれば十分です。
| 用語 | 主な役割 | イメージ |
|---|---|---|
| Git | ファイルの変更履歴を管理する | 変更を記録する仕組み |
| GitHub | Gitのプロジェクトを共有し、共同作業を支える | チームの共有スペース |
| リポジトリ | ファイルと変更履歴をまとめて管理する | プロジェクトごとの保管箱 |
| README | プロジェクトの目的や使い方を説明する | 保管箱の入口にある案内文 |
→リポジトリ:ファイルと変更履歴を管理する単位
→リポジトリ:ファイルと変更履歴を管理する単位
→README:プロジェクトの目的や使い方を伝える案内文
→README:プロジェクトの目的や使い方を伝える案内文
2. リポジトリは、ファイルと履歴をまとめる単位
リポジトリには、コードや資料などのファイルと、それらの変更履歴が含まれます。GitHubでは、個人や組織がリポジトリを所有し、アクセス権限を管理します。GitHub公式:リポジトリについて
「保管箱」というたとえは便利ですが、普通のフォルダとまったく同じではありません。現在のファイルに加えて、記録された過去の変更も扱える点が特徴です。
たとえば、記事を作るプロジェクトなら、次のように整理できます。
article-project/
├── README.md … このプロジェクトの説明
├── articles/ … 記事の原稿
├── images/ … 記事で使う画像
└── docs/ … 執筆や確認の手順
この構成は一例であり、決まったフォルダ名を使わなければならないわけではありません。「READMEを読めば、どこに何があるかわかる」状態を目指します。
自分のパソコンとGitHubの関係
自分のパソコンにあるリポジトリを「ローカルリポジトリ」、共有先にあるものを「リモートリポジトリ」と呼びます。GitHub上のリポジトリは、リモートの一例です。GitHubから履歴を含むコピーを作る操作は、clone(クローン)と呼ばれます。GitHub公式:リポジトリの用語
パソコンでファイルを編集しただけでは、GitHub側の内容は自動的に同じになりません。 ローカルで変更を記録し、共有先へ送る作業が必要です。履歴へ記録する操作をcommit(コミット)、リモートへ送る操作をpush(プッシュ)と呼びます。具体的な操作は別のテーマとして学び、ここでは「手元と共有先は分かれている」と覚えておきましょう。GitHub公式:リポジトリのクイックスタート
→ローカルリポジトリ:自分のパソコン
→手元のファイルを編集する
→ローカルの変更を履歴に記録する
→リモートリポジトリ:共有先(GitHubは一例)
3. READMEは、初めて訪れた人のための案内文
READMEは、プロジェクトの概要や使い始め方を伝えるファイルです。GitHubは、所定の場所に置かれたREADMEをリポジトリの入口に表示します。初めて訪れた人が最初に読む資料になりやすいので、「このプロジェクトは何か」が伝わることが大切です。GitHub公式:READMEについて
小さなプロジェクトでは、最上位のフォルダにREADME.mdを置くと理解しやすくなります。.mdはMarkdown形式のファイルによく使われる拡張子です。Markdownでは、簡単な記号で見出しや箇条書き、リンクを書けます。GitHub公式:基本的な書式
READMEに書いておきたいこと
以下は、この記事で提案する小規模プロジェクト向けの構成です。
| 項目 | 読者が知りたいこと | 記載例 |
|---|---|---|
| 目的 | 何のためにあるのか | 学習メモを記事にまとめる |
| 内容 | 何が入っているのか | 原稿、画像、確認手順 |
| 始め方 | 最初に何をすればよいか | 原稿フォルダの見本を読む |
| フォルダ構成 | どこを見ればよいか | 原稿はarticles、手順はdocs |
| 注意点 | どんな前提があるのか | 公開前に画像の利用条件を確認する |
| 問い合わせ先 | 困ったらどうするか | このリポジトリのIssueへ連絡する |
読み手に必要な入口を先に書き、詳しい説明は別の資料へリンクすると、READMEを読み進めやすくできます。情報を増やすより、最初の一歩がわかることを優先しましょう。
4. 小さなREADMEを書いてみる
記事作成用の架空のプロジェクトなら、次のようなREADMEから始められます。問い合わせ先のIssueは、そのリポジトリで利用できる場合の例です。
# 学習記事プロジェクト
ITの学習メモを、読みやすい記事にまとめるための保管場所です。
## 入っているもの
- articles:記事の原稿
- images:記事で使う画像
- docs:執筆と確認の手順
## 最初に読むもの
articlesフォルダの見本記事を読み、原稿の構成を確認してください。
詳しい手順は [執筆ガイド](docs/writing-guide.md) にあります。
## 公開前の確認
- 内容と参照元を照合する
- 個人情報や社内の非公開情報が含まれていないか確認する
- 画像の利用条件を確認する
## 問い合わせ
不明点は、このリポジトリのIssueで相談してください。
この例では、#が大見出し、##がその下の見出し、-が箇条書きです。[表示する文字](リンク先)でリンクを書けます。例のdocs/writing-guide.mdは、READMEから見た相対的な位置を表しているので、実際にそのファイルを用意して使います。GitHub公式:基本的な書式、GitHub公式:README内の相対リンク
READMEは、他の人だけでなく、しばらく時間がたってから作業を再開する自分のためにも役立ちます。「なぜ作ったのか」「何から始めるのか」を残しておくと、再開する際の手がかりになります。
5. ブラウザで最初のリポジトリを作る
GitHubのアカウントにログインしていれば、最初のリポジトリとREADMEはブラウザから作れます。GitHub公式の手順は、新規作成、名前の入力、公開範囲の選択、READMEの追加、作成という流れです。GitHub公式:リポジトリのクイックスタート
練習では、次の手順で試してみましょう。
- GitHubの「New repository」から、新しいリポジトリを作る画面を開く。
readme-practiceなど、内容がわかる名前を付ける。- 公開範囲を選ぶ。個人練習なら、まずはPrivateを選ぶと扱いやすい。
- READMEを追加する設定を有効にして、リポジトリを作成する。
README.mdを開き、編集機能から目的を1文、入れる予定のものを3項目書く。- プレビューで見出しや箇条書きを確認し、変更を記録する。チームのリポジトリでは、決められたブランチとレビューの手順に従う。
ここでの目標は、複雑な開発作業を覚えることではありません。自分が作った保管場所に、自分の言葉で案内文を置くことです。
- ログイン後、New repositoryを開く名前を入力する ↓
- 内容がわかる名前を付ける(例:readme-practice)公開範囲を設定する ↓
- 公開範囲を選ぶ(個人練習ではまずPrivate)READMEを追加して作成する ↓
- README追加を有効にしてリポジトリを作成するREADMEを開いて編集する ↓
- README.mdに目的を1文、予定するものを3項目書く表示を確認する ↓
- プレビューで見出しや箇条書きを確認する変更を記録する ↓
- 変更を記録する(チームでは所定のブランチとレビュー手順に従う)
6. 公開範囲と、READMEの更新を意識する
GitHubのPublicリポジトリは、インターネット上の誰でも閲覧できます。Privateリポジトリは、権限を持つ人がアクセスするものです。組織のリポジトリでは、組織の権限設定も関係します。GitHub公式:リポジトリの公開範囲
| 公開範囲 | 閲覧・アクセスできる人 |
|---|---|
| Public | インターネット上の誰でも閲覧できる |
| Private | 権限を持つ人がアクセスする |
実務で使うなら、保存先として認められているか、誰がアクセスできるかを確認しましょう。パスワード、APIキー、顧客情報、社内の非公開資料などを、練習用のリポジトリに入れる必要はありません。公開範囲を変える場合には、現在のファイルだけでなく、過去の履歴に何を記録したかも確認します。
また、READMEは一度書けば終わりではありません。フォルダを移動したり、使い方を変えたりしたら、説明も合わせて更新します。例の執筆ガイドが存在しない、案内された場所に原稿がない、といった状態では、読者が最初の一歩で止まってしまいます。
READMEを確認するときは、「初めて見る人が、説明だけで次の行動を選べるか」を基準にすると、修正すべき箇所を見つけやすくなります。
7. まとめと理解度確認
- GitHubは、Gitで管理するプロジェクトの共有や共同作業を支えるサービス。
- リポジトリは、ファイルと変更履歴をまとめて管理する単位。
- READMEは、そのプロジェクトの目的や使い始め方を伝える案内文。
最初は、READMEに「何のためのプロジェクトか」「何が入っているか」「最初に何をするか」を書くところから始めてみましょう。
自分の言葉で説明してみる
- GitとGitHubは、それぞれ何を担当しますか。
- リポジトリは、普通のフォルダとどの点が違いますか。
- READMEを読んだ人が、最初に知りたいことは何でしょうか。
- 手元のファイルを編集しただけで、GitHub側も更新されますか。
解答例
- Gitは変更履歴を管理し、GitHubはGitのプロジェクトを共有して共同作業を支えます。
- 現在のファイルだけでなく、記録された変更履歴も扱える点です。
- プロジェクトの目的、内容、使い始め方です。
- 自動的には更新されません。ローカルの変更を記録し、共有先へ送る作業が必要です。
参考資料
原資料には、記事の作成経緯として次の記載があります。
この記事は、添付画像にある「GitHub/リポジトリ/README」というテーマをもとに、GitHub公式資料を確認して作成しました。画像には講義本文や動画の文字起こしが含まれていないため、講義内容を再現した記事ではありません。
原資料に記載された資料確認日:2026年10月11日。
コメント