Git・GitHubとは?違いと使い方を初心者向けにわかりやすく解説
そもそも「バージョン管理」って何のため?

コードを書いていて、「さっきまで動いていたのに、直したら壊れてしまった」「元のファイルに戻したいのに、上書きしてしまってもう戻せない」——そんな経験はないでしょうか。
私も最初のころは、ファイルを「index_v2.html」、「index_v2_final.html_のようにコピーして残す、という原始的なやり方でごまかしていました。
ベトナム出身で、子どもの頃からの夢だったゲームやWebサービスづくりに、Claudeを相棒にして挑戦している私ですが、実はこの「ファイルのコピー地獄」から抜け出せたのは、Git・GitHubという仕組みを知ってからでした。
今回は、この2つが「結局何なのか」「何が嬉しいのか」を、自分のゲーム開発の実例も交えながらかみ砕いて紹介します。
Gitって何?(ファイルの変更履歴を記録する仕組み)

Gitは、ひとことで言うと「プロジェクトの変更履歴を記録してくれるツール」です。
ゲームでいうところの「セーブポイント」をイメージするとわかりやすいかもしれません。
Gitを使うプロジェクトのことをリポジトリ(repository、直訳すると「保管庫」)と呼びます。そしてキリのいいタイミングで「ここまでの変更を記録しておいて」と指示することをコミット(commit)と呼びます。コミットするたびに、その時点でのファイルの状態がスナップショットとして残っていくイメージです。
これの何が嬉しいかというと、
・「さっき動いていた状態」にいつでも戻せる
・どのタイミングで、何をどう変更したかが記録として残る
・ファイルを「○○_v2」や「○○_final」
のように増やさなくても、1つのファイルのまま履歴だけが積み重なっていくという点です。
バックアップというより「巻き戻しできる履歴付きの保管庫」というほうが近い感覚だと思います。
GitHubって何?(Gitとの違い・リモートに置くメリット)

ここで混同しやすいのが、GitとGitHubの違いです。
Git: 自分のパソコンの中で変更履歴を記録する「仕組み・ツール」そのもの
GitHub: そのGitの履歴(リポジトリ)を、インターネット上に置いて保管・公開できる「サービス」
つまり、Gitが「セーブ機能」だとすると、GitHubは「そのセーブデータをクラウドに預けておける場所」というイメージです。
自分のパソコンだけにリポジトリを置いていると、パソコンが壊れたら履歴ごと消えてしまいますが、GitHubに置いておけば
・パソコンが壊れてもコードと履歴が残る
・別のパソコンからでも同じプロジェクトを取ってこられる
・作ったものを他の人に見てもらったり、公開したりできる
というメリットがあります。ローカルの「git commit」で履歴を作り、「git push」でGitHubに送る、という流れが基本の使い方です。
実際のゲーム開発でどう使っているか

言葉の説明だけだとイメージしづらいと思うので、私が実際にClaudeと一緒に作っているサウンドノベルゲーム「駅までの5分」のコミット履歴を例に見てみます。
実際に「git log –oneline –reverse」(記録した順に一覧表示するコマンド)を打ってみると、こんな見た目になります。

こうやって並べてみると、「まず骨組みを作る→中身(シナリオ)を入れる→動く仕組みを作る→最後に素材で仕上げる」という開発の流れが、コミット履歴を見るだけでそのまま追える状態になっています。これは実装の途中経過を後から見返しても、「あのときはまだ音も画像もなかったんだな」と一目でわかる、ちょっとした開発日記のような役割も果たしてくれています。
コミットを積み重ねると何が嬉しいのか
このように区切りごとにコミットしておくと、
「進行ロジックを実装した直後」だけがなぜか動かなくなった、というときに、その1つ前のコミットと見比べて原因を絞り込める
「素材を追加したら急に重くなった」など、変更点ごとに影響を切り分けやすい
思い切った改造を試したいときも、「今の状態はコミットしてあるから、失敗してもいつでも戻せる」と思うと気軽に挑戦できる
といった安心感があります。Claudeと一緒にコードを書いていると、一気に大きな変更が入ることも多いので、この「いつでも戻せる」という感覚は特にありがたいと感じています。
初心者がまず押さえておきたい基本操作
最初から全部覚える必要はなく、まずはこの4つだけ押さえておけば十分です。
git init— このフォルダをGitで管理し始める(リポジトリを作る)
git add— 次にコミットする変更を選ぶ(記録する対象を「仮置き」する)
git commit— その時点の状態をひとつの記録として残す
git push— ローカルの記録をGitHubに送る実際にターミナル(コマンドを打ち込む画面)
でこれらを打ってみると、こんな流れになります。

最初は
git status(今どんな状態か教えてくれるコマンド)をこまめに打って、「今どのファイルが記録待ちなのか」を確認しながら進めると迷いにくいと思います。
流れとしては、
「ファイルを編集する→git addで対象を選ぶ→git commitで記録する→区切りのいいタイミングでgit pushする」
の繰り返しです。
慣れないうちは、Claude Codeに「今の変更をコミットしておいて」と頼んでしまうのも手だと思います。
コマンドが苦手なら、デスクトップアプリという選択肢もある

ここまでコマンドで説明してきましたが、実は同じことは画面をクリックするだけでもできます。代表的なのが、GitHub公式が無料で配布しているGitHub Desktopというデスクトップアプリです。
コマンドとの対応関係で見ると、こんな感じです。
git status
で確認していた「変更されたファイル」が、そのままチェックボックス付きの一覧として表示される
git add + git commit -m “…”
“…” は、コミットメッセージを入力欄に書いて「Commit to main」ボタンを押すだけ
git push は、右上の「Push origin」ボタンを押すだけ
変更した行が緑色でハイライトされるので、
diff
(変更差分)も一目でわかる
「コマンドを一字一句間違えずに打つ」というハードルがなくなるぶん、最初の一歩としてはこちらのほうが気楽かもしれません。
普段はコマンドで操作しつつ、履歴をパッと見返したいときだけデスクトップアプリを開く、という組み合わせ方もできます。
どちらが優れているというより、コマンドとデスクトップアプリはあくまで同じGitへの「入り口の違い」なので、自分がやりやすいほうから始めて大丈夫です。
おまけ:Claude Codeの新規プロジェクト画面にもGitが登場する

ここまでの説明を知っていると、Claude Code(デスクトップアプリ)の中でもGitの気配に気づけるようになります。
新しいプロジェクトを作ろうとすると、プロジェクト名の横に「main」という表示と、「ワークツリー」というボタンが並んでいるのを見たことはないでしょうか。
「main」はブランチ(branch、作業を枝分かれさせる仕組み)の名前です。ここまでは触れていませんでしたが、Gitは1本の履歴だけでなく、途中から履歴を分岐させて、別の作業を並行して進めることもできます。
特に何も指定しなければ、多くのプロジェクトは main という名前のブランチを土台にして進んでいくので、そこが表示されているわけです。
「ワークツリー」は、Gitのworktreeという機能に対応しています。
通常、1つのプロジェクトフォルダでは同時に1つのブランチしか作業できませんが、worktreeを使うと、同じプロジェクトの別ブランチを別フォルダとして切り出し、同時に開いておくことができます。
Claude Codeでこれを使うと、今取り組んでいる作業のファイルには手を加えずに、別フォルダ・別ブランチでClaudeに別の試作品を作ってもらう、といった並行作業がしやすくなります。
普段は意識せずに使っていても差し支えありませんが、「このmainって何だろう」「ワークツリーって何のボタンなんだろう」と思ったときは、ここまで紹介してきたGitの仕組みそのものだと思い出してもらえたらと思います。
まとめ:次にやってみること

Gitは「変更履歴を記録する仕組み」、GitHubは「その履歴をネット上に置いて保管・共有できる場所」——この違いさえ押さえておけば、最初のとっつきにくさはかなり減ると思います。私自身、ファイルをコピーして残す運用から抜け出せたことで、「壊れても戻せる」という安心感を持って開発に挑戦できるようになりました。
次は、今ローカルにしか置いていないプロジェクトをGitHubに
push
して、パソコンが壊れても大丈夫な状態を作ってみようと思います。

