GitHubの仕組み~プログラムやファイルの「過去の履歴」を完全に記録しながら、複数人で安全に「共有・共同編集」するための仕組み~

GitHubの重要概念・仕組み一覧表

分類用語・概念概要と役割重要なポイント
全体像(階層構造)アカウントすべての起点の場所個人用と組織用があり、複数人で共同管理する基盤となる。
リポジトリプロジェクトごとのフォルダ公開・非公開を選べる専用の外箱
ブランチ作業するための並行世界本番データを壊さずに安全に実験・開発できる。
コミット&ファイルセーブデータと実際のファイルいつ、誰が、何をどう変えたかを履歴付きで記録する。
データの保存と同期コミットパソコン内へのセーブ操作ネット不要で、自分の裏側フォルダへ履歴を保存する。
プッシュネット上への同期操作手元のセーブデータをGitHubへ一括で送り込む
通常の保存との違い上書きではなく履歴の蓄積過去の任意の時点から100%元通りに復元できる。
複数人での共有クローン最初に行うダウンロードネットの箱をパソコンへ丸ごとコピーして開発環境を作る
プル日々のダウンロード仲間が更新した最新データを自分のパソコンに取り込む
衝突を防ぐ安全ルールコンフリクト(衝突)データのバッティング検知自動上書きでの消滅を防ぎ、エラーでプッシュをブロックする。
プルリクエスト変更の提案と審査本番に合体させる前に、仲間へレビューと承認を求める
マージデータの安全な合体審査後にボタン一つで本番環境へ安全に統合する。

GitHubは、プログラムやファイルの「過去の履歴」を完全に記録しながら、複数人で安全に「共有・共同編集」するための仕組みです。

1. 全体像:GitHubの「ピラミッド構造」

GitHubの中は、上から下へ向かって以下のような階層構造で整理されています。

階層 1:アカウント (所有者)
  └── 階層 2:リポジトリ (プロジェクトごとの大箱)
        └── 階層 3:ブランチ (作業するための並行世界)
              └── 階層 4:コミット&ファイル (セーブデータと実際のファイル)

① アカウント(最上階:場所の所有者)

すべての起点です。これがないと場所を作れません。

  • 個人アカウント:あなた個人の持ち物(個人の部屋)。
  • Organization(組織アカウント):企業やサークルなどの組織(共有オフィス)。複数のメンバーを所属させて共同管理します。

② リポジトリ(2階:プロジェクトごとの外箱)

プロジェクトごとに作成する「専用のフォルダ」です。

  • パブリック(公開):世界中の誰もが中身を見たり、ダウンロードしたりできます。
  • プライベート(非公開):あなたと、あなたが「招待した仲間」だけがアクセスできる秘密の箱です。

③ ブランチ(3階:作業するための「並行世界(枝)」)

1つのリポジトリの中で、本番のデータを壊さずに安全に作業するための「歴史の分岐路」です。

  • メイン(本番)ブランチ:一般に公開する、またはバグのない「完成品」を置くメインストリート。
  • 作業用ブランチ:新機能の開発やバグ修正のために、メインから一時的に枝分かれさせた実験用の場所。ここでどれだけ失敗しても本番には影響しません。

④ コミットとファイル(最下層:データの正体)

ブランチの奥にあるのが、実際のファイルと「コミット(変更履歴)」です。ただの保存ではなく、「いつ、誰が、どのファイルを、どう変えたか」というメッセージカードを添えて記録されます。

2. コミットとプッシュの真実:どこに何が保存される?

「通常の保存」と「Gitの保存」は、保存される場所も仕組みも全く異なります。

【あなたのパソコン(手元)】                          【GitHub(ネット上)】
 📁 作業フォルダ
   ├── 📄 ファイル(目に見える最新版)
   └── 📁 .git (隠しのセーブ保管庫)
          │
      [① コミット] (手元にセーブ)
          │
          └─────────── [② プッシュ] (ネットへ同期) ───────────> ☁️ GitHub上のリポジトリ

① コミット(Commit)とは?

  • 場所:自分のパソコンの作業フォルダの裏側にある「.git」という隠しフォルダ。
  • やっていること:その瞬間のファイルのコピー(スナップショット)を取り、あなたの書いた「コミットメッセージ(理由のメモ)」と一緒に、裏側のローカルリポジトリ(.git)へガッチャンコと保存します。
  • 状態:まだあなたのパソコンの中にしかありません。インターネットが繋がっていなくても実行できます。

② プッシュ(Push)とは?

  • 場所:インターネット上にある「GitHubのサーバー」。
  • やっていること:手元の隠しフォルダ(.git)に溜まったセーブデータを、インターネットを経由してGitHub上の同じリポジトリ(リモートリポジトリ)へ一括で送り込みます。
  • 状態:これで初めてネット上にデータが同期され、他の人が見たりダウンロードしたりできるようになります。

通常のファイル保存との決定的な違い

通常の保存(上書き保存)は、過去のデータを「消して」最新にするだけです。

Gitのコミットは、「その瞬間のファイル丸ごと」+「過去の歴史」の両方を圧縮して裏側に別名で保存し続けています。そのため、ファイルをゴミ箱に捨ててしまっても、過去の任意のコミットからいつでもファイル本体を100%元通りに復元できます。

3. 複数人で「共有」する完全プロセス

GitHubを使った共有は、お互いのパソコンと、真ん中にある「GitHubの箱(リモートリポジトリ)」を仲介して行われます。

  【Aさんのパソコン】              【GitHub(中央の箱)】             【Bさんのパソコン】
📁 Aさんの作業フォルダ             ☁️ リモートリポジトリ              📁 Bさんの作業フォルダ
       │                                  ▲                                  │
       └─── [1. プッシュ(送信)] ───────┤                                  │
                                          └─── [2. クローン/プル(受信)] ──>┘

メンバー間でファイルを共有する手順は、以下の3つのステップで進みます。

ステップ1:GitHubに「共有の箱」を作る

プロジェクトの代表者が、GitHub上に「リモートリポジトリ」を作成します。

その箱の住所(例: https://github.com/ユーザー名/プロジェクト名.git)を、一緒に作業するメンバーに伝えます。

ステップ2:データを手元に持ってくる(最初の一回:クローン)

新しく参加するメンバー(Bさん)は、教えてもらった住所を使って、GitHubの箱をフォルダごと自分のパソコンに丸ごとコピーします。

この最初のダウンロード操作を クローン(Clone) と呼びます。これで、Bさんの手元にも.git(隠しセーブデータ保管庫)を含めた完全な開発環境が作成されます。

ステップ3:日々の変更を送り合い、受け取る(プッシュ & プル)

  • Aさんが変更したとき:Aさんはファイルを編集し、手元で「コミット」し、GitHubへ「プッシュ」します。
  • Bさんがそれを受け取るとき:Bさんは、GitHubの箱から最新のデータを自分のパソコンに引っ張ってきます。このダウンロードして手元のファイルと合体させる操作を プル(Pull) と呼びます。

4. 衝突を防ぐ安全な合体ルール

もし、AさんとBさんが同時に同じファイルの同じ行を書き換えて、それぞれプッシュしようとしたらどうなるでしょうか?

普通の共有フォルダ(Dropboxなど)なら、後から保存した人が前の人のデータを「上書き消滅」させてしまいます。

しかし、GitHubにはこれを防ぐ2つの強力なセーフティネットがあります。

セーフティ 1:コンフリクト(衝突)の検知

もし変更箇所がバッティングしている場合、GitHubは「自動で合体できません!」とエラーを出し、プッシュをブロックします。

そして、ファイルの中に以下のようなマークを自動で書き込み、どちらの変更を残すかを人間に選ばせます。

<<<<<<< HEAD
Aさんの書いたコード(手元)
=======
Bさんの書いたコード(GitHub側)
>>>>>>> 123456789...

二人はこれを見て話し合い、「両方残す」か「片方にする」かを決めて整理(競合解消)してから、改めてコミット&プッシュします。これにより、データが勝手に消える事故を100%防げます。

セーフティ 2:プルリクエスト(Pull Request / プルリク)

チーム開発では、いきなり本番のメインブランチに直接プッシュすることはしません。必ず以下の「提案と審査」のステップを踏みます。

[作業ブランチで開発] ──> [プルリクエスト(提案)] ──> [仲間がレビュー・承認] ──> [マージ(合体)]
  1. 作業用ブランチを作る:本番のメインブランチから枝分かれした「自分専用の作業スペース」で作業をします。
  2. プルリクエストを送る:作業が終わったら、「作業ブランチの変更を、本番のメインブランチに合体(プル)していいですか?」とGitHub上で仲間にリクエスト(提案)を送ります。
  3. レビューと相談:仲間は、GitHubの画面上で「どこがどう変わったか」を1行ずつ確認し、「ここ、もっとこうしよう」「OK、バッチリ!」といったコメントを書き込んで会話します。
  4. マージ(Merge):全員のOKが出たら、合体ボタンを押して本番のメインブランチに安全に統合(マージ)します。

まとめ:GitHubの日常会話

GitHubを使うとき、チーム内ではこのような会話が日常的に行われます。このガイドを読んだあなたなら、もうすべての意味が直感的に理解できるはずです!

  • 「新しいプロジェクト始めたから、リポジトリのURL共有するね。まずクローンしといて!」(=ネットの箱から、フォルダ丸ごと手元にコピーしてね)
  • 「今日の作業、バグ修正が終わったからコミットしてプッシュしといたよ」(=手元でセーブ記録を作って、ネットの共有場所にアップロードしたよ)
  • 「作業を始める前に、必ずプルしてね」(=他の人が更新した最新の状態を、自分のパソコンに取り込んでから作業してね)
  • 「機能追加できたから、メインブランチに向けてプルリク送ったよ。確認してマージお願いします!」(=本番に合体していいかレビューを求めたよ。OKなら合体ボタンを押してね)