そもそも Git と GitHub とは何か ― 違い・役割・2つのサイクルを1枚の地図にする

AI にコードを書かせていると、ふいにこう聞かれます。「いったんコミットしておきますか？ 」「変更をプッシュしますか？ 」。あるいは誰かに「プルリクください」と言われて、返事に詰まる。

Git、GitHub、コミット、プッシュ、プルリク。言葉は毎日のように飛び交うのに、「で、Git と GitHub って何が違うの？ 」と正面から聞かれると、意外と答えに詰まるのではないでしょうか。

この記事は、コマンドを覚えるためのものではありません。Git と GitHub が、それぞれ何のための道具で、どう違い、どう連携するのか。その地図を 1 枚、頭の中に作るための超入門です。操作は AI に任せていい。でも地図がないと、AI に何を頼めばいいのかが分かりません。

TL;DR

• Git は、自分の PC の中で「変更の履歴」を記録し、いつでも好きな時点に戻せる道具です。ゲームのセーブに近い仕組みです。
• GitHub は、その履歴をインターネット上に置いて、保管・公開・共同作業をする場所です。Git のための「置き場＋協業の場」です。
• 覚えることは 2 つのサイクルだけ。手元で回す「Git のサイクル」と、ネット越しに回す「GitHub のサイクル」。この地図があれば、操作は AI に任せても的確に指示できます。

Git は、何のためにあるのか

こんなファイルを作った経験はないでしょうか。

企画書_最終版.docx
企画書_最終版_修正.docx
企画書_最終版_田中さん指摘反映.docx
企画書_最終版_本当にこれで最後.docx

私も Git を知る前は、こういうファイルをよく量産していました。どれが本物か分からなくなります。手で複製していくやり方には、避けられない限界があります。いつ・誰が・なぜ変えたのかが残らない。消したコピーは戻らない。複数人が触れば上書きし合う。

Git は、この限界をまとめて解決する道具です。正式にはバージョン管理システム (変更の履歴を記録し、いつでも元に戻せるようにする仕組み) と呼びます。やっていることを一言でいうと、こうです。

プロジェクト全体の歴史を、安全に・何度でも記録し、いつでも好きな時点に戻せるようにする。

イメージはゲームのセーブポイントが近いです。区切りのいいところで状態を保存し、失敗したらそこに戻る。Git ではこの保存をコミット (commit) と呼びます。ゲームと違うのは、セーブを無限に作れて、過去のセーブが全部残り、しかも枝分かれして並行で進められることです。

だから Git は「失敗を恐れる」ための道具ではなく、「安心して失敗できる」ための道具です。こまめにセーブしておけば、何を壊しても戻せる。AI に思い切ったコードを書かせて試す、という今の働き方と相性がいいのは、この安心感があるからです。

Git が生まれた背景

今の形になった理由は、生まれた事情を知ると腹落ちします。

Git は 2005 年、Linux OS(世界中のサーバーを動かしている OS) の生みの親リーナス・トーバルズと、Linux 開発コミュニティが作りました。きっかけは少し変わっています。それまで Linux 開発で使っていた商用のツール (BitKeeper) が、2005 年に無償で使えなくなってしまったのです。代わりが必要になり、彼らは自分たちで新しい道具を作りました。それが Git です。

最初から狙っていた設計目標は、速いこと・分散していること・何千もの枝分かれをさばけること・巨大なプロジェクトでも耐えること。世界中の何千人もの開発者が同時に関わる Linux 開発を支えるためでした。だから Git は今も、速くて頑丈で、枝分かれに強いのです。この経緯は Git公式の解説 にまとまっています。

「分散」というのは、複製した時点で全部の履歴が自分の手元にまるごと来る、という意味です。ネットがつながっていなくても、セーブも履歴の閲覧もできます。この「分散」と、Git が変更を写真のように丸ごと記録する「スナップショット」という 2 つの仕組みが、Git の心臓部です。ここをもっと深く知りたい方は、Gitの中身を内側から見る記事 で内部構造まで掘り下げています。

Git で回す「手元のサイクル」

実際に Git を使うときは、3 つの場所をファイルが行き来します。

• 作業ディレクトリ …いま編集しているファイルそのもの
• ステージング …次のセーブに含める変更を選んでおく控え室 (買い物カゴのようなもの)
• ローカルリポジトリ …セーブの履歴が積み上がっていく置き場

flowchart TD A["作業ディレクトリ<br/>編集中のファイル"] -->|"git add でカゴに入れる"| B["ステージング<br/>次のセーブに含める控え室"] B -->|"git commit でセーブ"| C["ローカルリポジトリ<br/>セーブの履歴"] C -.->|"いつでも過去のセーブに戻れる"| A

流れはシンプルです。ファイルを編集して、git add で「次のセーブに入れる変更」をカゴに入れ、git commit でセーブする。区切りのいいところで、これを繰り返すだけです。カゴ (ステージング) をはさむのは、変更したものすべてではなく、まとまりのある分だけをセーブしたい場面があるからです。

このサイクルは全部、自分の PC の中だけで完結します。ネットは要りません。これが Git の基本です。

AI に頼むなら、難しいコマンドを覚える必要はありません。「区切りがいいので、いまの状態をコミットしておいて」とひと言頼めば、AI が add と commit をやってくれます。あなたが握るのは「いつセーブするか」という判断だけです。

Git と GitHub は、何が違うのか

ここが、いちばん混同されるところです。結論から言うと、Git と GitHub は別物です。

• Git …自分の PC で動く道具 (ソフトウェア)。インストールして使う。
• GitHub …その Git の履歴を預かってくれる Web サービス (会社が運営している)。インターネット上にある。

喩えるなら、Git は手元のカメラです。写真 (セーブ) を撮る道具そのもの。GitHub は、撮った写真をアップロードして共有するクラウドアルバムです。カメラがあれば写真は撮れます。でも他の人に見せたり、スマホが壊れても写真がなくならないようにするには、クラウドに上げておくと安心です。その関係に似ています。

大事なのは最後の行です。GitHub は「Git の履歴をネットに置く場所」の代表格ですが、唯一ではありません。同じ役割を持つ GitLab や Bitbucket もあります。GitHub はその中でいちばん使われている、という位置づけです。

つまり、Git があれば 1 人でも開発は完結します。GitHub は、その Git を「ネットに広げて、保管し、人と協力する」ために足すものです。

GitHub の役割

GitHub が引き受けてくれる仕事は、大きく 2 つです。

1 つめは、置き場としての役割です。手元の PC にある履歴を、ネット上のもう 1 か所にも持っておく。PC が壊れても履歴は無事ですし、別の PC からでも取り出せます。この「ネット上の置き場」を正式にはリモート (remote) と呼び、登録するときは慣習で origin(オリジン) という名前を付けます。「みんなの置き場＝リモート、その名前が origin」と覚えておけば、公式ドキュメントを読んでも迷いません。

2 つめは、協業の基盤としての役割です。代表が Pull Request(プルリクエスト、略してプルリク) です。これは「この変更を取り込んでください」と提案し、中身をレビューしてから合流させる仕組みです。ほかにも、課題を管理する Issue(イシュー) や、作業を自動化する Actions(アクションズ) など、複数人で開発を回すための道具がそろっています。

GitHub は 2008年に登場し、今は Microsoft の傘下にあります (2018年に買収完了)。1 人で使ってもメリットがあります。バックアップになり、作品を公開でき、あとから誰かが参加するときの受け皿にもなります。

GitHub で回す「ネット越しのサイクル」

Git の手元サイクルが分かっていれば、GitHub のサイクルは「それをネット越しにやりとりするだけ」です。手元 (Git) と GitHub、2 か所の拠点を行き来します。

flowchart TD R["GitHub・リモート origin<br/>ネット上の共有リポジトリ"] -->|"clone 最初に複製する"| L["手元のPC・Git<br/>編集→add→commit を回す"] L -->|"push アップロードする"| R R -->|"pull 最新を取り込む"| L

基本の動きは 3 つです。

• clone(クローン) … GitHub にあるプロジェクトを、まるごと手元に複製する。最初の 1 回だけ。
• push(プッシュ／アップロード) …手元でセーブした履歴を、GitHub に送る。
• pull(プル／ダウンロード) … GitHub 側の最新を、手元に取り込む。

1 人で使うなら、これだけでバックアップと公開ができます。手元で Git のサイクルを回してセーブし、区切りで push して GitHub に上げる。それだけです。

複数人で使うときは、ここに Pull Request が入ります。自分の変更を別の作業場 (ブランチ) で作り、push して、「取り込んでいいですか」と Pull Request を出す。仲間がレビューして、問題なければ合流 (マージ) する。この流れがあるから、いきなり本番を壊さずに、安心して変更を持ち寄れます。

ここでも、コマンドを手で打つ必要はありません。「GitHub に上げておいて」「最新を取り込んで」と頼めば、AI が push と pull をやってくれます。あなたが分かっているべきは、「いま手元と GitHub の、どちらが新しいか」という地図のほうです。

用語ミニ辞典―身近なものに喩えると

Git と GitHub の世界には、聞き慣れない言葉がたくさん出てきます。ここまで登場した言葉を、身近なものに喩えて並べます。意味を忘れたら、ここに戻ってきてください。

喩えは、あくまで入り口です。慣れてきたら喩えを外して、正式な名前 (commit、branch、push…) だけで考えられるようになります。そのころには、AI に「ブランチを切って試して」「プルリクにまとめて」と頼むのが、自然になっているはずです。

まとめ

Git と GitHub を、最後にもう一度 1 枚に整理します。

• Git は手元の道具。変更の歴史をセーブし、いつでも戻せる。サイクルは「編集→ add → commit」。
• GitHub はネット上のサービス。Git の履歴を保管・公開・協業する。サイクルは「clone → push → pull」、チームなら「ブランチ→ Pull Request →マージ」。
• 違いは一言でいえば、Git＝道具、GitHub＝その道具をネットに広げる場所。GitHub は数ある置き場の代表格で、唯一ではありません。

覚えることは、この 2 つのサイクルだけです。コマンドは忘れていい。むしろ AI に任せていい。でも、この地図さえ持っていれば、「いまコミットして」「GitHub に上げて」「プルリクにして」と、AI に何を頼めばいいのかが分かります。手を動かすスキルより、何を頼むか分かる頭のほうが、AI 時代には長く効きます。

もう一歩進みたい方へ。Git の心臓部である分散とスナップショットの中身は Gitの中身を内側から見る記事 で、Git のインストールと初期設定は 環境構築の記事 で、日々使うコマンドは 毎日のコマンドの記事 で、Pull Request の実際の流れは プルリクエストの記事 で、それぞれ手を動かしながら確かめられます。