GitHubって何？ソースコードを管理する仕組みをやさしく解説 🐙
プログラムを書く人たちが「変更履歴を残しながら」「複数人で」安全に作業するための仕組みを、やさしいレベルから順番に理解できます。
1. GitHubとは
GitHubは、プログラムを書いた人たちが、自分の作業を保存して、みんなで見せ合うための場所です。
たとえば、グループで自由研究のレポートを作るとして、Googleドキュメントで一緒に書いたことがある人は多いと思います。GitHubは、それの「プログラム専用版」だとイメージしてください。
- レポートを書くたびに「いつ・誰が・どこを直したか」が全部記録される
- 1人が書いた部分を、別の人が見て直すこともできる
- 間違えても、前のバージョンに戻せる（ゲームのセーブデータをロードする感覚に近い）
つまりGitHubは、**「プログラムのための、共同作業ノート＋セーブデータの保管庫」**です。
なぜこんな仕組みが必要なのでしょうか。プログラムは、1人で書いていても何十回・何百回と書き直すものです。さらに会社のシステムや人気のアプリになると、何十人・何百人のエンジニアが同時に同じプログラムに手を入れます。もしメモも記録もなく、ファイルを直接上書きし合っていたら、誰かの作業が消えたり、「動いていたのに、いつの間にか壊れた」が頻発してしまいます。GitHubは、この混乱を防ぐために生まれました。
世界中の会社や個人のエンジニアが、自分たちのプログラムをここに置いて、変更を記録しながら開発しています。たとえば、スマホアプリ、Webサービス、ゲーム、AIモデルなど、いま使われているソフトウェアの多くが、GitHub（または似たような仕組み）の上で作られています。学校の課題で作る小さなプログラムから、世界中で使われる大きなサービスまで、規模に関係なく同じ仕組みが使われているのが特徴です。
また、GitHubには「誰でも見られる公開の場所」という側面もあります。多くのエンジニアは、自分の作ったプログラムを無料で公開し、世界中の人がそれを参考にしたり、改善を手伝ったりしています。プログラミングを学ぶときに、教科書だけでなく「実際に世界中で使われているプログラムそのもの」を見て学べる場所、という捉え方もできます。
2. 仕組みをもう少し深掘りする
ここからは少し専門的な言葉が出てきますが、1つずつ分解すれば難しくありません。
まず大事な区別が1つあります。
- Git（ギット）：変更履歴を記録する「仕組み」そのもの。自分のパソコンの中で動くソフトウェア。
- GitHub（ギットハブ）：そのGitの記録を、インターネット上に保管して人と共有できる「サービス」。
Wordの「変更履歴を記録する」機能を、プログラム全体に対して使えるようにしたのがGitです。そのGitの記録をクラウドに置いて、誰とでも共有できるようにしたのがGitHub、という関係になります。
GitHub上でよく使う言葉を表にまとめます。
| 用語 | 意味 | たとえ |
|---|---|---|
| リポジトリ（repository） | プロジェクト全体を入れる「箱」 | プロジェクトごとのフォルダ |
| コミット（commit） | 「ここまで変更しました」という記録の1単位 | レポートのセーブポイント |
| ブランチ（branch） | 本流から分かれた作業用のコピー | 別バージョンの下書き |
| プルリクエスト（pull request） | 「この変更を本流に取り込んでください」という提案 | 先生に提出する下書きチェック依頼 |
| マージ（merge） | プルリクエストが承認され、本流に取り込まれること | 下書きが正式なレポートに採用される |
| Issue（イシュー） | バグ報告や「やることリスト」 | 付箋に書いたタスク・不具合メモ |
作業の流れは、次のようになります。
1. リポジトリをパソコンにコピーする（clone）
2. ブランチを切って自分の作業スペースを作る
3. ファイルを編集し、変更を記録する（commit）
4. GitHub上にアップロードする（push）
5. プルリクエストを出し、誰かにレビューしてもらう
6. 問題なければ本流に取り込む（merge）
この流れがあるおかげで、「誰が・いつ・なぜ・何を変えたか」がすべて記録に残り、何人で同時に作業しても混乱しません。
3. 実際の使用例で理解する
具体的にどんな場面で使われるか、2つの例で見てみましょう。
例1：学校の文化祭サイトをチームで作る場合
3人で文化祭の案内サイトを作るとします。GitHubがないと、誰かが書いたファイルを別の人が上書きしてしまい、せっかくの作業が消えるかもしれません。GitHubを使うと、3人がそれぞれブランチを切って同時に作業し、最後にプルリクエストでまとめて確認しながら1つのサイトに統合できます。
例2：自分のプログラムを後から直す場合
半年前に書いたプログラムにバグが見つかったとき、コミットの履歴をさかのぼれば「いつ、どこを、なぜ変えたか」が分かります。何も記録していないと「前は動いていたのに、どこを直したら壊れたか」が分からなくなりますが、Gitの履歴があれば原因を特定しやすくなります。
使うときに気をつけたいポイントもまとめておきます。
- 公開（Public）と非公開（Private）の違いを確認する：Publicリポジトリは世界中の誰でも内容を見られます。個人情報やパスワードを含むコードは必ずPrivateにする。
- パスワードやAPIキーをコードに直接書かない：一度GitHubに記録すると、後から削除しても履歴に残ってしまうことがあります。
- README（リードミー）を用意する：リポジトリの最初に表示される説明書。何のプロジェクトで、どう使うかを書いておくと、自分も他人も後から理解しやすくなります。
- Issue・プルリクエストでやり取りする：口頭やチャットで伝えるより、Issueやプルリクエストにコメントを残す方が、後から「なぜその変更をしたか」を追跡できます。
4. まとめ
- GitHubは「プログラムのための共同作業ノート＋セーブデータの保管庫」
- Gitは変更履歴を記録する仕組み、GitHubはそれをクラウドで共有するサービス
- 作業の単位は「コミット」、提案は「プルリクエスト」、取り込まれることを「マージ」と呼ぶ
- 文化祭サイト制作やバグ修正のように、複数人での共同作業や過去の変更の追跡に役立つ
- Public/Privateの設定を必ず確認し、パスワードやAPIキーは直接コードに書かない