本書について

本書を手に取っていただき、ありがとうございます。

ネットで検索すれば、Gitの情報はいくらでも出てきます。それなのに、なぜわざわざ本を買うのか——そう思われる方も多いのではないでしょうか。

もしかすると、「Git」という言葉を初めて聞いて気になったから、という方もいらっしゃるかもしれません。でも大半の方は、一度ネットの情報を頼りにGitを学ぼうとして、挫折した経験があるのではないでしょうか。

実は筆者もGit挫折経験者です。それも2回。

最初は「なんか難しそうだし、そもそも必要性がわからない」と感じて投げ出しました。その後、本格的な開発業務に携わるようになり、必要に迫られてネットの情報を頼りに再挑戦。しかし、またしても挫折。2回の挫折を経験しています。

だからこそ、どこでつまずくのか、何がわかりにくいのか、身をもって知っています。そして不思議なもので、一度コツをつかむと「あれ、意外とシンプルじゃん」と拍子抜けするくらいスッと理解できるようになります。

挫折の原因は大きく2つあると考えています。

1つ目は、黒い画面への抵抗感です。コマンドを打ち込む画面は視覚的にわかりづらく、何が起きているのか見えません。コマンドを暗記しようとして、覚えられなくて嫌になる。

2つ目は、ネット情報の断片性です。ある程度知っている人でないと、欲しい情報にたどり着けません。そもそもどんなコマンドがあるか知らないのだから、調べようがないのです。「そんなこともできるの!?」と後から驚かされることばかりでした。

今やGitはエンジニアにとっての常識です。開発現場でGitをスラスラ使えるエンジニアは、それだけでプロっぽく見えます。AI時代になってもこの状況はしばらく続くでしょう。むしろ、AIと協働する時代だからこそ、Gitの重要性は増しています。

本書は、この2つの挫折ポイントを乗り越えられるように設計しました。黒い画面で何が起きているのか、多くの図解で視覚的に「見える化」しています。そして、断片的な情報ではなく、Gitの全体像から個々のコマンドまで体系的に学べる構成にしました。コマンドを暗記するのではなく、「なぜそうするのか」を理解することで、自然と使えるようになります。

本書があなたのエンジニアとしての第一歩を踏み出す手助けになれたら、筆者としてこれほどうれしいことはありません。

シリーズ構成

本書「Why Git?」は2巻構成で、基礎から実践まで段階的に学べます。

Vol. I：基礎編（本書）

ローカル環境でのGit操作を基礎から学びます。Gitを初めて使う方、コマンドラインに不慣れな方でも、丁寧な解説で着実にスキルを身につけられます。

本書を読み終えると、一人でGitを使った開発ができるようになります。

Vol. II：マスター編

GitHubとの連携、コンフリクト解消、AIツールとの連携、チーム開発、CI/CDの実践的なワークフローを学びます。

Vol. IIを読み終えると、チーム開発で活躍できるGitスキルが身につきます。

本書の読み方

本書は第1章から順番に読むことをおすすめします。各章は前の章の知識を前提としているため、途中から読むと理解しづらい箇所があるかもしれません。

ただし、すでにGitの基本を知っている方は、必要な章から読み始めても構いません。各章の冒頭に「この章で学ぶこと」がまとめてあるので、参考にしてください。

各セクションの見出しには「もくじへ戻る」ボタンがあります。復習したいときや特定のコマンドを確認したいときは、目次に素早く戻って開きたいページを選ぶことができます。

1章1 AI時代の開発スタイル もくじ

プログラミングの世界は大きく変わりました。GitHub Copilot、Claude Code、ChatGPTといった定番ツールに加え、Cursor、Devin、Windsurf、Cline、そしてGoogleのAntigravityなど、新しいAI開発ツールが次々と登場しています。あなたがこの本を手に取ったということは、すでにこれらのツールを使っているか、これから使おうとしているのではないでしょうか。

AIがもたらした開発の変化

AIツールの登場により、開発スタイルは根本から変わりつつあります。

従来、プログラマーは「コードを書く」ことに多くの時間を費やしていました。しかし今、プログラマーの役割は「AIに何を作らせるか指示する」方向へシフトしています。「プロンプトエンジニアリング」という言葉が示すように、AIへの指示の仕方そのものが新しいスキルになりました。

この変化により、プログラミングの敷居は大きく下がりました。AIの助けを借りれば、経験の浅い人でもアプリを作れる時代です。しかし同時に、新たな課題も生まれています。

非エンジニアがぶつかる壁

AIの登場で、これまでプログラミングに触れたことのない方でもアプリを作れる時代になりました。マーケター、デザイナー、経営者——職種を問わず「AIと一緒に開発する」という選択肢が広がっています。

しかし、AIで開発を始めた非エンジニアの多くが、ある段階で壁にぶつかります。

コードは書ける。動くものは作れる。でも、プロジェクトが大きくなるにつれて「なんだかうまくいかない」状況が増えていく。ファイルがぐちゃぐちゃになる。昨日動いていたものが今日は動かない。チームで作業しようとすると混乱する。

この壁の正体は、エンジニアが当たり前に使っている「暗黙のルール」を知らないことです。

長年の開発現場で培われてきた定石、業界標準のツール、チーム開発のお作法——これらはエンジニア教育の中で自然と身につくものですが、AI経由で開発を始めた方には触れる機会がありません。

その代表格がGitです。

エンジニアにとってGitは空気のような存在。使えて当たり前のツールです。しかし、「Git」という言葉を本書で初めて聞いたという方も少なくないのではないでしょうか。

もしあなたがその一人なら、本書を手に取ったのは幸運です。Gitは単なるツールではなく、プロの開発現場に入るための「入場券」のようなもの。これを知っているかどうかで、この先の開発体験は大きく変わります。

本書では、Gitの基礎はもちろん、なぜそうするのかという背景も丁寧にお伝えします。将来エンジニアとして活躍したいと思ったとき、すでに業界標準の開発手法が身についている——そんな状態を目指しましょう。

Gitとは何か

では、Gitとは一体何でしょうか。

一言で言えば、ファイルの変更履歴を記録・管理するツールです。

普段、あなたはファイルを保存するとき、上書き保存をしていると思います。でも「昨日の状態に戻したい」と思ったら？ 上書きしてしまった後では、もう戻せません。

Gitを使うと、ファイルの「スナップショット」を好きなタイミングで保存できます。いつでも過去の状態に戻れるし、「いつ、誰が、何を、なぜ変更したか」も記録に残ります。

ゲームのセーブポイントをイメージしてください。ボス戦の前にセーブしておけば、負けても何度でもやり直せます。Gitはプログラミングにおけるセーブポイントのようなものです。

なぜ今Gitを学ぶのか

「ファイルの履歴管理なら、Dropboxや Google ドライブでもできるのでは？」と思うかもしれません。

答えはシンプルです。AIの出力は毎回異なり、一発で完璧なコードが生成されることはほとんどありません。AIとの開発は「試行錯誤の連続」なのです。

たとえば、こんな場面を想像してください。AIに「ログイン機能を作って」と依頼したとします。

1. 1回目: AIがコードを生成。動かしてみるとエラーが出る
2. 2回目: エラーを伝えて修正依頼。動くようになった!
3. 3回目: 「もっと良くしたい」とデザイン修正を依頼。見た目は変わったが、なんか違う
4. 4回目: さらに修正を依頼。どんどん迷走していく…

この繰り返しがAI開発の現実です。そして、ここで問題が起きます。「2回目の時点では動いていたのに…あの状態に戻りたい」と思っても、どうやって戻ればいいのでしょうか？

Gitを使っていれば、各段階を「コミット」として記録できます。「2回目の状態に戻りたい」と思えば、コマンド一つで復元できます。迷走する前の「動いていた状態」にすぐ戻せるのです。

つまり、GitはAIとの試行錯誤を安全に行うためのセーフティネットなのです。AIが強力になればなるほど、試行錯誤の回数も増えます。だからこそ、Gitの価値は高まっているのです。

1章2 AIコード生成の3つのリスク もくじ

AIは強力ですが、適切な管理なしに使うと思わぬ落とし穴があります。ここでは、AI開発で特に注意すべき3つのリスクを見ていきましょう。

リスク1: 予期せぬ変更

AIに「ボタンの色を変えて」とお願いしたら、関係ないファイルまで書き換えられていた——そんな経験はありませんか？

AIは指示した箇所だけでなく、「ついでに」他の部分も変更してしまうことがあります。親切心からの改善かもしれませんが、意図しない変更は思わぬバグの原因になります。2025年には、AIがデータベースを誤って削除するという事故も報告されています。

Gitがあれば: git diffで「何が変わったか」を一目で確認できます。意図しない変更があれば、その部分だけ元に戻すことも簡単です。

リスク2: 品質・セキュリティの問題

「動いた！」と喜んでデプロイしたコードに、実はセキュリティの穴が空いていた——これは珍しい話ではありません。

AI生成コードの約半数がセキュリティテストで問題を指摘されるというデータもあります。AIは「今、動くコード」を書くのは得意ですが、「安全なコード」や「後でメンテナンスしやすいコード」という観点は弱いのです。

Gitがあれば: コードレビューの際に変更履歴を追えます。「いつ、どんな変更が入ったか」がわかるので、問題の原因特定も容易です。

リスク3: 再現できない

「さっきは動いていたのに…」——AIとの開発でよく聞く言葉です。

同じプロンプトを投げても、AIは毎回少し違うコードを生成します。「あのとき動いていたバージョン」を再現しようとしても、二度と同じコードは生成されません。記憶を頼りに手動で戻そうとすると、かえって状況を悪化させることも。

Gitがあれば: 動いていた状態をコミットとして保存できます。迷走してもgit checkout一発で、確実に動いていた状態に戻れます。

1章3 バージョン管理がない開発の限界 もくじ

ファイル名による管理の悪夢

app_最終版.js、app_最終版2.js、app_本当の最終版.js——こんなファイル名を見たことはありませんか？

バージョン管理を使わないと、こうなります。どれが最新かわからない。何が違うのかわからない。いつ変更したのかわからない。なぜ変更したのかは、もう誰も覚えていない。

チーム開発では、この混乱が人数分だけ掛け算されます。「田中さんの最終版」と「鈴木さんが直したやつ」、どっちが正しいのか。メールやチャットで確認する時間が、コードを書く時間を圧迫していきます。

「どこまで戻ればいいかわからない」問題

AI開発で特に厄介なのが、「さっきまで動いていたのに」という状況です。

AIに修正を頼む → 動かなくなる → 別の修正を頼む → さらに悪化する。この繰り返しで、気づけば最初の状態から遠く離れてしまいます。

「動いていた状態に戻りたい」と思っても、どの時点が「動いていた状態」なのか、ファイル名では特定できません。記憶を頼りに手動で戻そうとすると、別のバグを埋め込んでしまうことも。

こうした問題を解決するのが、次節で紹介するGitとAIの組み合わせです。

1章4 AIとGitの役割分担 もくじ

ここまで、AIコード生成のリスクとバージョン管理の重要性を見てきました。では、AIとGitはどう組み合わせればいいのでしょうか。

「攻め」と「守り」の関係

AIは「攻め」の担当。 コードを高速に生成し、次々と提案を出してきます。「こう書いたらどう？」「この機能も追加しようか？」と、積極的に前に進もうとします。

Gitは「守り」の担当。 AIが生成したコードを確実に記録し、問題が起きたら以前の状態に戻せるようにします。「ここまでは大丈夫だった」という安全な地点を守り続けます。

この役割分担があるからこそ、AIの提案を気軽に試せるのです。失敗しても、Gitが守っている「安全な地点」に戻ればいい。攻めと守り、両方があって初めて安心して開発を進められます。

実践的なワークフロー

具体的には、こんな流れで開発を進めます。

1. 現在の状態をGitで保存（コミット）
2. AIに機能追加や修正を依頼
3. 動作確認して問題なければGitで保存
4. 問題があればGitで前の状態に戻す

この繰り返しです。AIが「攻め」て、うまくいったらGitで「守り」を固める。うまくいかなかったら、Gitで守っていた地点まで戻って再挑戦。

このワークフローを身につければ、AIとの開発で迷走することはなくなります。本書では、この流れを実践的に学んでいきます。

1章5 本書で学べること、到達できるレベル もくじ

本書（Vol. I：基礎編）は、Gitを基礎から学ぶための実践的ガイドです。全6章を通じて、「Gitとは何か」という概念からローカル環境での実践まで、段階的に学習していきます。

各章の学習内容

第1章（本章）

AI時代になぜGitが必要なのかを理解します。AIツールの爆発的普及、実際の失敗事例、バージョン管理の重要性、そしてGitとAIの相互補完関係を学びます。

第2章「Gitの基本概念を理解しよう」

リポジトリ、コミット、ブランチといったGit特有の概念を、初心者にもわかりやすく解説します。「ローカルリポジトリとリモートリポジトリの違い」「コミットは追加であって上書きではない」といった、初心者が躓きやすいポイントを重点的に説明します。

第3章「開発環境を整えよう」

Git、VS Codeのインストールと設定を行います。無料で使えるツールを中心に、頻出するトラブルシューティングまで、実務で必要な環境構築をカバーします。

第4章「ターミナルを使ってみよう」

Gitを使うために必要なターミナル（コマンドライン）の基礎を学びます。ターミナルとは何か、GUIとCLIの違い、基本的なコマンド操作（ls、cd、mkdir、pwd）など、黒い画面への苦手意識を克服し、自信を持ってコマンドを入力できるようになります。

第5章「Gitコマンド入門」

実務で使う主要Gitコマンドを体系的に解説します。init、status、add、commit、log、diff、branch、switch、merge、restoreなど、各コマンドの用途、オプション、実例を豊富に掲載。今すぐ覚える必要はありません。使いながら慣れていきましょう。

第6章「ローカルでGitを実践しよう」

実際の開発フローに沿って、コマンドを組み合わせた実践演習を行います。リポジトリの作成から、新機能開発、バグ修正、複数ブランチの並行開発といった実務シナリオを通じて、第5章で学んだコマンドを実践で使いこなせるようになります。

本書で習得できるスキル

本書を学習することで、あなたは以下のスキルを習得できます：

• Gitの基本概念（コミット、ブランチ、マージ）の完全な理解
• ローカルリポジトリでの実践的なGit操作
• ブランチを使った安全な開発手法
• VS CodeとGitの連携
• 一人開発でのGitワークフロー

Vol. II：マスター編について

本書を読み終えたら、ぜひ Vol. II：マスター編にも挑戦してください。GitHubとの連携、AIツールとの連携、チーム開発の実践的なワークフローを学べます。

• GitHubと連携しよう（push, pull, clone）
• AIツールとGitを連携させよう（GitHub Copilot, Claude Code）
• チーム開発で活躍しよう（Pull Request, コードレビュー）
• トラブルシューティングと応用テクニック

学習の進め方

学習時間の目安は2〜3週間です。もちろん、あなたの経験や学習ペースによって前後しますが、本書の構成は「確実に一歩ずつ前進できる」ように設計されています。

AI時代の開発は、かつてないほど可能性に満ちています。AIツールの力を借りれば、初心者でも驚くほど高品質なコードを書けるようになります。しかし、その力を最大限に引き出すには、確実な「土台」が必要です。それがGitです。

本書を通じて、あなたは「失敗を恐れない」開発スタイルを身につけることができます。AIの提案を積極的に試し、うまくいかなければ元に戻し、成功したら次のステップへ進む。そんなダイナミックな開発サイクルを、自信を持って回せるようになります。

次章からは、具体的なGitの学習に入っていきます。まずは第2章で、Gitの基本概念をしっかりと理解しましょう。

1章6 本書のコマンド表記と読み方 もくじ

本書では、多くのコマンド例が登場します。「コマンド」という言葉を聞いて、うっ…と身構えてしまう方もいるかもしれません。大丈夫です。

今すぐ覚える必要はありません。 本書では、コマンドが登場するたびに一つ一つ丁寧に説明します。「覚える」のではなく「使いながら慣れる」のが一番の近道です。

また、後述しますが、GitはVS Codeなどのエディタからボタン操作でも使えます。ただし、コマンドでしかできない操作も多いため、本書ではコマンドを中心に解説します。最初は戸惑うかもしれませんが、繰り返し使っているうちに自然と手が動くようになります。

なお、本書で登場するコマンドにはGitコマンドとBashコマンドの2種類があります。Gitコマンドは git で始まるコマンド、Bashコマンドはそれ以外のターミナル操作コマンドです。本書の本題はGitですのでBashコマンドの詳細は割愛しますが、よく使うものは第4章で紹介します。

このセクションでは、本書で使われる表記ルールを解説します。ここを理解しておけば、後の章でスムーズに学習を進められます。

ターミナル（コンソール）とは

ターミナル（またはコンソール、コマンドライン）は、文字を入力してコンピュータに指示を出すツールです。OSによって標準のターミナルが異なります。

本書では「Git Bash」を基準にします

Windowsユーザーへの重要なお知らせ: 本書では、Windowsでも「Git Bash」を使用することを前提としています。Git BashはGitをインストールすると一緒にインストールされるbashシェルで、MacやLinuxと同じコマンドが使えます。

PowerShellやコマンドプロンプトでは、一部のコマンド（ls、catなど）が動作しなかったり、出力形式が異なったりします。本書の内容をそのまま試すには、Git Bashを使用してください。

本書では、ターミナルでの操作を以下のような黒い背景のボックスで表示します。

$ git status
On branch main
nothing to commit, working tree clean

プロンプト記号の違い

ターミナル表示で重要なのが、行頭のプロンプト記号です。お使いの環境によって表示が異なります。

本書では $ で統一しています。 お使いの環境で % や > が表示されていても、$ の後に書かれているコマンドをそのまま入力してください。

$ git status
On branch main

$ がある行: あなたが入力するコマンド（$ 自体は入力しない） $ がない行: コンピュータからの出力（結果）

つまり上の例では、git status と入力すると、On branch main という結果が返ってきます。

ターミナルの言語設定について

本書のコマンド出力は英語表示を基準にしています。 お使いの環境が日本語設定の場合、出力メッセージが日本語で表示されることがあります。

# 英語環境（本書の表示）
$ git status
On branch main
nothing to commit, working tree clean

# 日本語環境（お使いの環境）
$ git status
ブランチ main
コミットするものがありません、作業ツリーはきれいです

どちらでも動作に違いはありません。本書の英語メッセージと異なる表示でも、同じ意味であれば問題なく進められます。

コメント（#）の意味

コード内の # は「コメント」の始まりを示す記号です。# からその行の終わりまでがコメントとして扱われ、コンピュータには無視されます。つまり、入力する必要はありません。

# この行は全体がコメント（入力不要）
$ git add index.html    # ←この部分だけがコメント

• 1行目: 行の先頭に # があるので、行全体がコメント
• 2行目: git add index.html がコマンド、# 以降の説明文はコメント

上の例で実際に入力するのは git add index.html の部分だけです。

Gitコマンドとbashコマンドの違い

本書で登場するコマンドは、大きく2種類に分けられます。

Gitコマンド

git で始まるコマンドはすべてGitコマンドです。バージョン管理の操作を行います。

$ git init          # Gitリポジトリを初期化
$ git add .         # ファイルをステージング
$ git commit -m "メッセージ"  # コミットを作成
$ git push          # リモートに送信
$ git pull          # リモートから取得

bashコマンド（シェルコマンド）

git で始まらないコマンドは、一般的なシェルコマンドです。ファイル操作やシステム操作を行います。

$ ls                # ファイル一覧を表示
$ cd my-project     # ディレクトリを移動
$ cat index.html    # ファイルの内容を表示
$ mkdir new-folder  # 新しいフォルダを作成

これらはGitとは直接関係ありませんが、開発作業では頻繁に使います。本書でも状況確認のために登場することがあります。

オプションの読み方

コマンドには「オプション」を付けて動作を変えることができます。

$ git log --oneline    # 履歴を1行ずつ表示
$ git commit -m "メッセージ"  # コミットメッセージを指定
$ ls -la               # 隠しファイルも詳細表示

ハイフン1つ（-）: 短いオプション（例: -m, -a） ハイフン2つ（--）: 長いオプション（例: --oneline, --all）

短いオプションは1文字、長いオプションは単語で指定します。同じ意味のオプションが短い形式と長い形式の両方で用意されていることもあります（例: -m と --message は同じ意味）。

プレースホルダーの表記

本書では、実際の値に置き換える部分を <> で囲んで示します。

$ git commit -m "<message>"
$ git switch <branch-name>
$ git clone <repository-url>

上の例では、<message> の部分を実際のメッセージ（例: "Initial commit"）に置き換えて実行します。<> 自体は入力しません。

複数行のコマンド

コマンドが長い場合、\（バックスラッシュ）で改行することがあります。

$ git log --oneline \
    --graph \
    --all

これは実際には1つのコマンドです。\ は「次の行に続く」という意味で、すべてを1行で入力しても同じ結果になります。

出力の省略

出力が長い場合、... で省略することがあります。

$ git log
commit a1b2c3d4e5f6a7b8...
Author: Your Name <email@example.com>
Date:   Mon Jan 15 10:00:00 2025 +0900

    Initial commit
...

本書の表記規則まとめ

1章7 Git Bashの開き方 もくじ

前のセクションで「WindowsユーザーはGit Bashを使いましょう」とお伝えしました。ここでは、Git Bashを開く方法を説明します。

Git Bashを開く方法はいくつかありますが、VS Code（Visual Studio Code）から開くのがおすすめです。VS Codeは第3章で詳しく解説しますが、プログラミングで最も使われているエディタです。

VS Codeでターミナルを開く手順

1. VS Codeを起動して、プロジェクトフォルダを開きます
2. メニューから開く: 左上のメニューアイコン→「Terminal」→「New Terminal」を選択

ショートカットキー（Windows: Ctrl+`、Mac: Cmd+`）でも開けます。

ターミナルが開くと、画面下部にコマンドを入力できるパネルが表示されます。

上の画像ではシンプルに $ だけが表示されていますが、お使いの環境では user@PC名 ~/project $ のようにユーザー名やフォルダパスが表示されているかもしれません。Git Bashでは色付きで装飾されていることもあります。表示が違っても問題ありません。$ や % の後にコマンドを入力できれば大丈夫です。

$ の後にコマンドを入力し、Enter（Return）キーを押すと実行されます。多くのコマンドは、成功すると何もメッセージを返さずに次のプロンプトが表示されます。「何も起きていない？」と不安になるかもしれませんが、エラーメッセージが出ていなければ成功です。「便りがないのは良い便り」と覚えておきましょう。

Windowsユーザーの場合: 初回は PowerShell が開くことがあります。その場合は、ターミナルパネル右上の「+」ボタン横の「∨」をクリックし、「Git Bash」を選択してください。

これで、VS Code内でターミナル（Git Bash）が使えるようになります。プロジェクトフォルダが自動的にカレントディレクトリになるため、すぐにGitコマンドを実行できます。

デフォルトをGit Bashに変更する（Windowsユーザー向け）

毎回Git Bashを選択するのが面倒な場合は、VS Codeのデフォルトターミナルをgit Bashに変更できます。

1. Ctrl+Shift+Pでコマンドパレットを開く
2. 「Terminal: Select Default Profile」と入力して選択
3. 「Git Bash」を選択

これで、新しいターミナルを開くと自動的にGit Bashが起動します。

1章8 まとめ もくじ

この章では、AI時代になぜGitが必要なのかを学びました。Gitはファイル管理ツールというだけでなく、AIとの協働を安全に進めるための「守り」の役割を担います。

この章で学んだこと

• Gitとは: ファイルの変更履歴を記録・管理するバージョン管理システム。いつでも過去の状態に戻れる
• AI時代にGitが必要な理由: 試行錯誤の記録、安全な実験、変更の追跡という3つの観点からGitの重要性が高まっている
• AIコード生成のリスク: 予期せぬ変更、品質・セキュリティの問題、再現性の欠如という3つのリスクがある
• AIとGitの役割分担: AIが「攻め」（コード生成）、Gitが「守り」（履歴管理・復元）を担当する
• コマンド表記ルール: $はプロンプト、#はコメント、<>はプレースホルダーを表す
• Git Bash: WindowsユーザーはGit Bashを使用することで、本書のコマンドをそのまま実行できる

理解度チェック

次章予告: 第2章では、リポジトリ、コミット、ブランチといったGitの基本概念を学びます。これらの概念を理解することで、Gitの動作原理がわかるようになります。

2章1 バージョン管理システムとは何か もくじ

「昨日まで動いていたコードが、なぜか動かない」「あの修正、元に戻したいけど、どこを変えたか覚えていない」——新機能を追加しようとコードを書き換えていたら、元々動いていた部分まで壊れてしまい、「Ctrl+Z」を連打しても、もう手遅れ。プログラムに触れたことがある人なら、誰もが一度は経験する悪夢です。

AIコーディングの時代になった今、この問題はさらに深刻になっています。AIが一度に大量のコードを生成・変更するため、「どこが変わったのか」「元はどうだったのか」を人間が把握することは、もはや不可能に近いのです。だからこそ、バージョン管理システムの重要性はかつてないほど高まっています。

バージョン管理システムとは、ファイルに対するすべての変更を自動的に記録し、いつでも過去の任意の時点に戻れるようにするツールです。いつ、誰が（あるいはどのAIが）、どのファイルの、どの部分を、どのように変更したのか——そのすべてが記録され、必要なときにいつでも参照できます。AIが生成したコードで問題が起きても、一瞬で「あのときの状態」に戻せる。これは、AIと協働する現代の開発者にとって、まさに命綱と言えるでしょう。

現代のソフトウェア開発において、バージョン管理システムは電気や水道と同じくらい当たり前のインフラです。使わない開発現場は存在しないと言っても過言ではありません。そして、その世界標準となっているのがGitです。

差分管理の威力——変更が「見える」ということ

Gitの強力さを実感できるのが「差分（Diff）」表示です。以下は、VSCodeでGitの差分を表示した画面のイメージです。

左側が変更前、右側が変更後のコードです。削除された行は赤色、追加された行は緑色でハイライトされています。この例では、従来のfor文をより簡潔なforEach文に書き換えています。

この差分表示があれば、AIが生成したコードでも、自分が深夜に書いたコードでも、「何がどう変わったのか」が一目瞭然です。問題が起きたとき、この差分を見れば原因の特定が格段に速くなります。そして、必要であればワンクリックで変更前の状態に戻すことができます。

これこそが、Gitを使う最大のメリットです。変更を「見える化」し、いつでも過去に戻れる安心感——それが、恐れずにコードを改善し続ける勇気を与えてくれます。

ボタン一つで元通り——Diff画面からワンクリックで戻す

「差分が見えるのはわかった。でも、実際に元に戻すのは難しいのでは？」と思うかもしれません。実は、VSCodeとGitの組み合わせなら、Diff画面からワンクリックで元に戻せます。

Diff画面で変更箇所を確認しているとき、変更ブロックの横に「→」と「+」のボタンが表示されます。「→」をクリックするだけで、その部分の変更が取り消され、元のコードに戻ります。コマンドを覚える必要はありません。ファイル全体ではなく、特定の変更ブロックだけを選んで元に戻せるのもポイントです。

AIにコードを書かせてみたものの、一部だけうまく動かない。そんなとき、問題のある部分だけをワンクリックで元に戻し、他の変更は残したまま別のアプローチを試せます。失敗を恐れず、何度でもやり直せる——これがGitのある開発環境です。

Gitの誕生ストーリー

Gitは2005年4月、Linuxカーネルの生みの親であるLinus Torvaldsによって作られました。その誕生には、ドラマチックな背景があります。

当時、世界最大級のオープンソースプロジェクトであるLinuxカーネルの開発には、BitKeeperという商用のバージョン管理システムが使われていました。BitKeeperは分散型で高性能でしたが、あるLinux開発者がBitKeeperのプロトコルをリバースエンジニアリングしたことで、無償ライセンスが取り消されてしまいます。数千人の開発者を抱えるLinuxコミュニティは、突然、開発ツールを失ったのです。

Torvaldsは既存のバージョン管理システム（CVSやSubversion）を検討しましたが、どれも彼の要求を満たしませんでした。彼が求めたのは以下の要件です。

• 分散型であること（中央サーバーに依存しない）
• 圧倒的な高速性（当時のツールは1パッチに30秒かかることもあった）
• 数千の並列ブランチを扱える非線形開発のサポート
• Linuxカーネルのような巨大プロジェクトを効率的に処理できること

「CVSを反面教師にした」とTorvaldsは後に語っています。「CVSがやっていることの正反対をやれば、だいたい正しい設計になる」と。

そして驚くべきことに、Torvaldsはわずか10日間でGitの最初のバージョンを完成させました。ただし、これは突然の思いつきではありません。彼はその前の4ヶ月間、BitKeeperを超えるシステムの構想を練り続けていたのです。2005年4月7日、Gitの最初のコミットが行われ、そのコミット自体がGitを使って記録されました。

分散型と集中型の違い

バージョン管理システムには「集中型」と「分散型」の2種類があります。Gitは分散型です。この違いを理解しておくと、Gitの動作がスムーズに理解できます。

集中型（SVNなど）

集中型では、プロジェクトの全履歴はサーバーだけが持っています。開発者の手元にあるのは「最新版のファイル」だけです。

これはつまり、サーバーが止まると全員が作業停止になるということです。履歴を見たい、過去のバージョンに戻したい、ブランチを作りたい…すべてサーバーへの接続が必要です。ネットワークが不安定な場所では、作業効率が大きく落ちます。

分散型（Git）

分散型では、全員が完全な履歴を持っています。git clone でリポジトリを複製すると、プロジェクトの最初から最新まで、すべての履歴があなたの手元にコピーされます。

だから、サーバー（GitHubなど）がダウンしても、手元で作業を続けられます。コミット、ブランチ作成、履歴の検索、すべてローカルで完結します。ネットワークが必要なのは、他の人と変更を共有するときだけです。

この違いは日常の開発体験に直結します。Gitでは「とりあえず試してみる」「過去の履歴を探る」といった操作が気軽にできます。ブランチ作成は一瞬。履歴検索もネットワーク遅延なし。この軽快さが、Gitが世界中で使われている理由の一つです。

なぜGitが世界標準になったのか

今やGitは、開発者にとって「使えて当たり前」のツールです。求人票に「Git必須」と書かれていることも珍しくありません。

ただ、Gitが最初から人気だったわけではありません。2005年の誕生から数年間は「Linuxカーネル開発者のための難解なツール」という印象が強く、一般の開発者にはなかなか浸透しませんでした。

転機となったGitHubの登場

状況を変えたのが、2008年のGitHubです。GitHubはGitリポジトリのホスティングに加えて、プルリクエスト、イシュー管理、コードレビューといった機能をWebから使えるようにしました。

特に「オープンソースプロジェクトは無料」という方針が決め手でした。個人開発者やオープンソースコミュニティがこぞってGitHubを使い始め、その流れが企業にも広がりました。2018年にはMicrosoftがGitHubを買収。今ではGitLabやBitbucketも含め、Git中心の開発エコシステムが完全に定着しています。

Gitが支持される理由

Gitが選ばれ続けているのには、技術的な理由があります。

• 速い: ブランチ作成、履歴検索、差分確認…ほとんどの操作がローカルで完結するので、ネットワーク遅延がありません
• 安全: すべてのデータがハッシュ値で管理されているので、破損や改ざんがあれば検出できます
• 柔軟: チームの規模や開発スタイルに合わせて、様々なワークフローに対応できます
• 無料: オープンソースなので、誰でも無料で使えます

2章2 Gitの世界観と用語ガイド もくじ

Gitには独自の用語がたくさんあります。「リポジトリ」「コミット」「ブランチ」「ステージングエリア」など、初めて聞くと混乱してしまうかもしれません。しかし心配は不要です。このセクションで、Gitの世界の全体像と基本用語を一度に把握してしまいましょう。

Gitの世界を俯瞰する

Gitでの作業は、大きく分けて「4つの場所」と「それらをつなぐ操作」で構成されています。まず、この全体像を頭に入れておくと、後の詳細解説がずっと理解しやすくなります。

この図が示す「場所」と「操作」の関係が理解できれば、Gitの8割は理解したも同然です。それぞれの詳細は2-3節以降で解説しますので、今は「こういう流れなんだな」と眺めるだけで大丈夫です。

基本用語クイックリファレンス

以下の表は、この章で詳しく学ぶ用語の一覧です。今は「こういう用語があるのか」と眺めるだけで大丈夫です。各セクションを読み進める中で、自然と理解が深まります。

場所を表す用語

概念を表す用語

操作を表す用語

後の章で学ぶ用語

本書の後半では、さらに以下の用語が登場します。

この章の読み方

この章は、上から順番に読むことをお勧めします。各セクションは前のセクションの知識を前提にしていますが、もし途中で用語が分からなくなったら、このセクションに戻って確認してください。

また、章末には「用語解説」ボックスがあります。そこでは全用語を一覧表形式でまとめているので、辞書的に活用できます。

では、次のセクションから各概念を詳しく見ていきましょう。

2章3 リポジトリ（ローカル/リモート）の違いと役割 もくじ

Git初心者が最初に躓きやすいのが、「リポジトリ」という概念です。特に「ローカル」と「リモート」の2種類があることを理解することが、Gitを使いこなす第一歩となります。

Gitワークフローの全体像

2-2節で見た図を、もう少し詳しく解説します。

Gitでの作業は「4つの場所」と「4つの操作」で構成されています。

4つの場所

• ワークツリー: あなたが実際にファイルを編集する場所です。VSCodeなどで開いているプロジェクトフォルダそのものです（「ワーキングディレクトリ」とも呼ばれます）
• ステージングエリア: 次のコミットに含めたい変更を選んで置いておく場所です（「インデックス」とも呼ばれます）
• ローカルリポジトリ: あなたのPC内にある履歴の保存場所です
• リモートリポジトリ: GitHubやGitLabなど、インターネット上にある共有の保存場所です

4つの基本操作

1. add: ワークツリーの変更をステージングエリアに追加
2. commit: ステージングエリアの内容をローカルリポジトリに記録
3. push: ローカルリポジトリの履歴をリモートに送信
4. pull: リモートリポジトリの履歴をローカルに取り込み

この流れを理解すれば、Gitの8割は理解したも同然です。では、それぞれの要素を詳しく見ていきましょう。

リポジトリとは何か

リポジトリ（Repository）とは、プロジェクトのファイルとその変更履歴を保存する場所です。単なるフォルダとは異なり、すべての変更の記録（誰が、いつ、何を変更したか）が含まれています。

リポジトリの実体は、プロジェクトフォルダ内にある.gitという隠しフォルダです。このフォルダには、コミット履歴、ブランチ情報、設定ファイルなど、Gitが動作するために必要なすべてのデータが格納されています。

「リポジトリを作る」とは具体的に何が起きるか

普通のフォルダをGitリポジトリに変換するには、git initコマンドを実行します。実際に何が起きるか見てみましょう。

# 普通のフォルダの状態
$ ls -la my-project/
drwxr-xr-x  3 user  staff   96 Jan 15 10:00 .
drwxr-xr-x  5 user  staff  160 Jan 15 10:00 ..
-rw-r--r--  1 user  staff  100 Jan 15 10:00 index.html

# git init を実行
$ cd my-project && git init
Initialized empty Git repository in /Users/user/my-project/.git/

# .git フォルダが追加された
$ ls -la
drwxr-xr-x  4 user  staff  128 Jan 15 10:00 .
drwxr-xr-x  5 user  staff  160 Jan 15 10:00 ..
drwxr-xr-x 12 user  staff  384 Jan 15 10:00 .git  ← これが追加された
-rw-r--r--  1 user  staff  100 Jan 15 10:00 index.html

この.gitフォルダこそがリポジトリの正体です。このフォルダが存在するかどうかで、「普通のフォルダ」と「Gitリポジトリ」が区別されます。

.gitフォルダの中身

.gitフォルダの中を覗いてみると、Gitがどのようにデータを管理しているかが分かります。

$ ls .git/
HEAD        # 今どのブランチにいるかを記録
config      # このリポジトリの設定
objects/    # コミットやファイルの実データ（圧縮して保存）
refs/       # ブランチやタグの情報
hooks/      # 自動実行スクリプト（上級者向け）

重要なのは、この.gitフォルダを削除すると、すべての履歴が消えてしまうということです。ファイル自体は残りますが、変更履歴は完全に失われます。逆に言えば、.gitフォルダさえあれば、過去のどの時点の状態にも戻ることができます。

ローカルリポジトリ

ローカルリポジトリは、あなたのコンピューター上に存在するリポジトリです。

特徴 - 自分のPC上に存在し、他の人からは見えない - インターネット接続なしで作業可能 - 自由に実験やテストができる「下書き」の場所 - git initコマンドで新規作成できる

ローカルリポジトリでは、コードの変更、コミット、ブランチの作成など、ほとんどの操作を完結できます。ネットワークに接続していなくても、過去の履歴を確認したり、新しい機能を開発したりすることが可能です。

リモートリポジトリ

リモートリポジトリは、GitHubやGitLabなどのサーバー上に存在するリポジトリです。

特徴 - インターネット上のサーバーに存在する - チームメンバーと共有するための「共有スペース」 - バックアップとしての役割も果たす - git cloneコマンドでローカルにコピーできる

リモートリポジトリは、チームでの共同作業の中心となります。各メンバーが自分のローカルリポジトリで作業し、完成した変更をリモートリポジトリに送信（push）することで、他のメンバーと作業を共有します。

同期の基本操作

ローカルとリモートの間でデータをやり取りする基本操作は3つです。

個人開発では、主にバックアップ目的でリモートリポジトリを使います。チーム開発では、メンバー間の変更を統合する中心的な役割を果たします。

2章4 コミットは「追加」、保存は「上書き」 もくじ

Gitを理解する上で最も重要な概念が「コミット」です。コミットは、通常のファイル保存とは根本的に異なる仕組みを持っています。

「上書き保存」と「コミット」の違い

普段の「保存」とGitの「コミット」は、役割が異なります。保存の代わりにコミットするのではなく、保存した上でコミットするという関係です。

ファイル保存（Ctrl+S / Cmd+S）は今まで通り必要

エディタで作業しているとき、Ctrl+Sを押してファイルを保存する——これは今まで通り必要です。保存しないとファイルの変更は反映されません。ただし、保存は「上書き」なので、保存するたびに以前の状態は消えていきます。エディタを開いている間はUndo（Ctrl+Z）で戻れますが、エディタを閉じるとそのUndo履歴も消えてしまいます。

コミットは「履歴ポイント」を作る操作

Gitのコミットは、保存とは別の操作です。「今のこの状態を、履歴として残しておきたい」と思ったタイミングで実行します。コミットすると、その瞬間のプロジェクト全体の状態が「履歴ポイント」として記録されます。

コミットA、コミットB、コミットC…と好きなタイミングで履歴ポイントを作っていけば、どの時点の状態にもいつでも戻ることができます。エディタを閉じても、PCを再起動しても、1年後でも関係ありません。コミットした時点の状態は永続的に保存されており、いつでもアクセスできます。

つまり、作業の流れはこうなります：

1. ファイルを編集する
2. Ctrl+Sで保存する（これは今まで通り）
3. 「この状態を残しておきたい」と思ったらコミットする
4. 1〜3を繰り返す

保存は「ファイルを更新する」操作、コミットは「履歴ポイントを作る」操作。この2つを組み合わせることで、いつでも過去に戻れる安心感が生まれます。

図を見ると違いは明らかです。上書き保存では過去のバージョンが次々と消えていきますが、Gitではすべてのコミットが残り続け、HEADを動かすだけでどの時点にも自由に移動できます。

コミットは「スナップショット」のイメージ

Gitのコミットは、その瞬間のプロジェクト全体の状態を丸ごと記録した「スナップショット（写真）」のようなものです。

コミットするたびに、プロジェクト全体の「写真」が1枚撮影されるイメージです。写真にはすべてのファイルが写っており、後から見返せば「あのときプロジェクトはこういう状態だった」と完全に再現できます。

ここが重要なポイントです。 過去に戻りたくなったら、その時点の「写真」を選ぶだけ。するとプロジェクト全体が、その写真を撮った瞬間の状態に一瞬で切り替わります。ファイルが100個あろうと1000個あろうと関係ありません。写真を1枚選ぶだけで、すべてのファイルがその時点の内容に戻るのです。

これがGitの「スナップショット」という考え方の本質です。差分を1つずつ巻き戻すのではなく、「その時点の完全な状態」をまるごと復元できる。だから、AIが大量のファイルを変更しても、コミットさえしておけば怖くありません。

技術的に言うと、Gitは各コミットでファイルの「差分」ではなく「完全な状態」を記録しています。ただし、内部的には効率化のため、変更のないファイルは前のコミットへの参照として保存されるので、ディスク容量を無駄に消費することはありません。

実際のコミット履歴を見てみよう

コミットは抽象的な概念ではありません。git logコマンドで、実際にどのように記録されているか確認できます。

$ git log --oneline
a1b2c3d (HEAD -> main) Add user authentication
e4f5a6b Update header design
c7d8e9f Initial commit

この出力から分かること：

• 各行が1つのコミット：上が新しく、下が古い
• 左の英数字（a1b2c3d）：コミットを一意に識別するID（コミットハッシュ）
• 右のメッセージ：コミット時に記録した説明（コミットメッセージ）
• HEAD -> main：今自分がいる場所を示している

ブランチの分岐やマージの様子を視覚的に確認したい場合は、--graphオプションを追加します。実務で最もよく使うコマンドの一つです。

$ git log --oneline --graph
* a1b2c3d (HEAD -> main) Merge branch 'feature/login'
|\
| * b2c3d4e Add login form validation
| * c3d4e5f Create login page
|/
* d4e5f6a Update README
* e5f6a7b Initial commit

*がコミットを表し、線で繋がれた分岐とマージの流れが一目で分かります。複数人で開発しているときや、ブランチを多用する場合に特に便利です。

より詳細な情報を見たい場合は、--onelineを外します。

$ git log
commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0 (HEAD -> main)
Author: Your Name <email@example.com>
Date:   Mon Jan 15 14:30:00 2025 +0900

    Add user authentication feature

このように、「誰が」「いつ」「何を」変更したかが完全に記録されています。

過去の状態を確認する

コミットが蓄積されていくと、「あのときのコードはどうなっていたか」を確認したくなることがあります。Gitなら簡単です。

# 2つ前のコミット時点のファイル内容を見る
$ git show c7d8e9f:index.html
<!DOCTYPE html>
<html>
<head><title>My App</title></head>
<body></body>
</html>

# 現在のファイル内容と比較
$ cat index.html
<!DOCTYPE html>
<html>
<head><title>My App - User Dashboard</title></head>
<body>
  <header>Welcome, User!</header>
  <!-- 多くのコードが追加されている -->
</body>
</html>

このように、過去のどの時点のファイル内容も、いつでも参照できます。これがGitの「すべて残る」という特徴です。

コミットハッシュ

各コミットには、一意の識別子（ID）が付与されます。これを「コミットハッシュ」または「SHA-1ハッシュ」と呼びます。

完全なハッシュ: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0（40文字）
短縮形:        a1b2c3d（最初の7文字）

コミットハッシュは、コミットの内容（変更されたファイル、作成者、日時、コミットメッセージなど）から自動的に計算されます。同じ内容のコミットは常に同じハッシュになり、内容が1文字でも異なれば全く違うハッシュになります。

短縮形で十分な理由

実際の操作では、40文字すべてを入力する必要はありません。Gitは短縮形でもコミットを特定できます。

# 以下はすべて同じコミットを指定できる
$ git show a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
$ git show a1b2c3d4e5f6
$ git show a1b2c3d

通常、最初の5〜7文字を指定すれば、プロジェクト内で一意にコミットを特定できます。Gitは入力された文字列に一致するコミットを自動的に検索し、該当するものが1つだけならそれを使用します。もし複数のコミットが同じ文字列で始まる場合は、Gitが「曖昧です」と警告を出すので、文字を1〜2文字追加すれば解決します。

なぜ衝突しないのか

SHA-1は16進数40文字（160ビット）の空間を持ちます。これは約10の48乗通りの組み合わせです。7文字の短縮形でも約2億6千万通りあるため、数千〜数万コミット程度のプロジェクトでは、実質的に衝突は起こりません。

Linuxカーネルのような巨大プロジェクト（100万コミット以上）でも、12文字程度で一意性が保たれています。

コミットハッシュの確認方法

# 直近のコミットのハッシュを確認
$ git log --oneline -1
a1b2c3d feat: ログイン機能を追加

# 完全なハッシュを表示
$ git log -1 --format="%H"
a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

git log --onelineでは、Gitが自動的に適切な長さの短縮形（通常7文字）を表示します。これをコピーしてそのまま他のコマンドで使用できます。

コミットメッセージの重要性

コミットには必ず「コミットメッセージ」を添えます。これは「何を」「なぜ」変更したかを記録するものです。

良いコミットメッセージの例

ユーザー認証機能を追加

- ログイン/ログアウト機能を実装
- セッション管理にJWTを採用
- パスワードはbcryptでハッシュ化

悪いコミットメッセージの例

修正

コミットメッセージは「未来の自分」や「チームメンバー」への手紙です。数ヶ月後に「なぜこの変更をしたのか」を思い出すために、具体的で意味のあるメッセージを書くことが重要です。

2章5 ブランチは「コミットにつけたラベル」 もくじ

ブランチは、Gitの最も強力な機能の一つです。しかし、多くの初心者がブランチについて誤解しています。この概念を正しく理解することで、Gitの真価を発揮できるようになります。

よくある誤解：ブランチ＝ファイルのコピー？

多くの初心者は「ブランチを作る＝プロジェクト全体をコピーする」と考えがちです。フォルダを複製してproject_v1、project_v2と管理していた経験があると、この誤解に陥りやすいでしょう。

誤解: ブランチを作ると、ファイルがコピーされる

正解: ブランチは、コミットへの「ポインタ（参照）」にすぎない

上の図が示すように、ブランチの実体は非常にシンプルです。各ブランチは単に「どのコミットを指しているか」という情報（40文字のハッシュ値）を持っているだけです。ブランチを作成しても、ファイルは一切コピーされません。

この設計により、以下のメリットが生まれます：

• 作成が一瞬: ブランチ作成は数十バイトのファイルを1つ作るだけ
• 容量を消費しない: 1000個のブランチを作っても、追加容量はわずか数KB
• 切り替えが高速: ポインタの参照先を変えるだけなので瞬時に完了

この「軽量ブランチ」こそが、Gitが他のバージョン管理システムと一線を画す特徴です。気軽にブランチを作り、実験し、不要になれば削除する。この柔軟性が、モダンな開発ワークフローを支えています。

なぜブランチが必要なのか

ブランチの必要性は、具体的なシナリオで考えると分かりやすくなります。

状況: あなたは新機能「ダークモード」を追加したいと考えています。しかし、うまく実装できるか分かりません。試行錯誤が必要で、場合によっては失敗するかもしれません。

ブランチがない場合の問題:

mainブランチで直接開発を始めると、試行錯誤の過程で動いていたコードが壊れる可能性があります。「やっぱりやめよう」と思っても、どこまで戻せばいいか分からなくなります。最悪の場合、元々動いていた機能まで壊してしまうかもしれません。

ブランチがある場合の解決策:

ブランチを使えば、「完成版のコード」と「開発中のコード」を完全に分離できます。

main ブランチ        → 完成して動作確認済みのコード
feature/dark-mode   → ダークモードを開発中（まだ未完成）

ダークモードの開発はfeature/dark-modeブランチで進めます。このブランチでどれだけコードを変更しても、mainブランチには一切影響しません。開発が完了し、十分にテストして動作確認ができたら、そのタイミングでmainにマージ（統合）します。

もし開発がうまくいかなかったら？そのブランチを削除するだけです。mainブランチは最初から最後まで安全なまま。今まで動いていた機能には一切影響を与えません。

具体的なコマンドと、それぞれの操作後の状態を見てみましょう。

ポイントは、git switchでブランチを切り替えると、フォルダ内のファイルが実際に書き換わるということです。同じフォルダなのに、ブランチによって中身が変わる。これがGitの魔法です。

git switch main      # 新しい書き方（推奨）
git checkout main    # 古い書き方（今でも動く）

このように、ブランチを使えば複数の作業を完全に分離できます。お互いに影響を与えることなく、並行して作業を進められるのです。

ブランチの仕組み

ブランチの実体は、40文字のコミットハッシュが書かれた小さなファイルです。.git/refs/heads/ディレクトリを覗くと、各ブランチに対応するファイルが見つかります。

$ cat .git/refs/heads/main
e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4

$ cat .git/refs/heads/feature
d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3

このように、ブランチファイルの中身は単なるハッシュ値です。新しいコミットを作ると、このハッシュ値が新しいコミットのものに更新されます。

ブランチを切り替える（git switch）と、Gitは以下の処理を行います：

1. HEADの更新: 現在のブランチを示すHEADポインタを切り替え先に変更
2. ファイルの復元: 切り替え先コミットの状態にワークツリーを更新
3. インデックスの更新: ステージングエリアも切り替え先の状態に同期

上の図は典型的なブランチの流れを示しています。コミットBの時点でfeatureブランチを作成し、その後mainとfeatureがそれぞれ独立して進み、最終的にマージ（統合）されています。

ブランチを切り替えると実際に何が起きるか

ブランチの切り替えは、単なる「表示の切り替え」ではありません。ファイルの内容が実際に変わります。

# feature/dark-mode ブランチで新機能を開発中
$ git switch feature/dark-mode
Switched to branch 'feature/dark-mode'

$ cat styles.css
body {
  background: #1a1a1a;  /* ダークモードの背景色 */
  color: #ffffff;
}

# main ブランチに切り替える
$ git switch main
Switched to branch 'main'

$ cat styles.css
body {
  background: #ffffff;  /* 通常の背景色 */
  color: #333333;
}

同じファイル（styles.css）なのに、ブランチを切り替えると内容が変わっています。これは、Gitが.gitフォルダ内に保存されているデータを元に、ファイルを書き換えているのです。

この仕組みにより、1つのプロジェクトフォルダで複数の開発ラインを管理できます。ファイルを手動でコピーしたり、複数のフォルダを用意したりする必要はありません。

HEADとは

HEADは、「今自分がいる場所」を示す特別なポインタです。地図アプリで「現在地」を示すピンのように、Gitの世界での「今ココ」マーカーだと考えてください。Gitで作業するとき、常に「どこにいるか」を把握していることが重要です。HEADがその役割を担っています。

通常、HEADはブランチ名を指しており、そのブランチが指すコミットが現在の作業状態となります。この「二段階の参照」構造を理解することが、Gitを使いこなす鍵です。

上の図のように、HEADは通常「ブランチ」を指し、ブランチが「コミット」を指します。新しいコミットを作ると、現在のブランチのポインタが自動的に新しいコミットに移動します。HEADは変わらずそのブランチを指し続けるので、結果的にHEADも最新コミットを参照することになります。

ブランチを切り替える（git switch feature）と、HEADの指す先が変わります。

$ git switch main
Switched to branch 'main'
# HEAD → main → コミットE

$ git switch feature
Switched to branch 'feature'
# HEAD → feature → コミットD

# コミットハッシュを直接指定してcheckout
$ git checkout a1b2c3d
# または
$ git switch --detach a1b2c3d

# 現在のコミットに新しいブランチを作成
$ git switch -c my-new-branch

mainブランチ

リポジトリを作成すると、デフォルトでmainブランチが作られます。一般的に、mainブランチには「本番環境で動作する安定したコード」を置きます。

新機能の開発やバグ修正は、mainから分岐した別のブランチで行い、完成したらmainにマージ（統合）するのが標準的なワークフローです。

実務でのブランチ運用

「branch」は日本語で「枝」を意味します。mainブランチが木の「幹」、そこから伸びるfeatureブランチやbugfixブランチが「枝」というイメージです。

実際のソフトウェア開発現場では、mainブランチ上で直接開発作業をすることはまずありません。多くの企業やチームでは、ブランチの運用ルールが明確に定められています。

典型的なルールの例を挙げましょう。「mainブランチへの直接コミットは禁止。必ず作業用ブランチを作成し、プルリクエスト（PR）経由でマージすること」「PRには最低1人のレビュー承認が必要」「CI（自動テスト）が通らないとマージできない」といった具合です。

なぜここまで厳格なのでしょうか。mainブランチは多くの場合、本番環境に直結しています。ここにバグのあるコードが入ると、ユーザーに影響が出ます。だからこそ、mainは「守るべき聖域」として扱われ、変更を加える際には複数のチェックを通過させるのです。

日常の開発フローはこうなります。まず担当するタスク用のブランチを作成します（feature/user-profileなど）。そのブランチで実装を進め、完成したらプルリクエストを作成。チームメンバーがコードをレビューし、問題がなければmainにマージされます。

個人開発であっても、この習慣を身につけておくことをお勧めします。mainで直接作業する癖がついてしまうと、チーム開発に参加したときに苦労します。また、個人でも「動く状態のmain」を常に維持しておけば、いつでも安心してデプロイできる状態を保てます。

ブランチの活用シーン

ブランチは用途に応じて命名規則を決めると管理しやすくなります。

$ git switch -c experiment/copilot-refactor

2章6 インデックス（ステージングエリア）の役割 もくじ

Gitには「ステージングエリア」（インデックスとも呼ばれる）という独自の仕組みがあります。他のバージョン管理システムにはない、Git特有の概念です。

なぜステージングが必要なのか

ステージングエリアは、Linuxカーネル開発という大規模プロジェクトの要求から生まれました。1日に何百もの変更が発生する環境では、「どの変更を1つのコミットにまとめるか」を細かく制御する必要がありました。

ステージングエリアがないと、作業ディレクトリの変更をすべてまとめて1つのコミットにするか、ファイル単位でしかコミットを分けられません。ステージングエリアがあることで、「意味のある単位」でコミットを作成できます。

具体的なシナリオ：部分的にコミットしたい

状況: 2つのファイルを変更しましたが、1つは完成、もう1つはまだ作業中です。

# 現在の状態を確認
$ git status
Changes not staged for commit:
  modified:   login.js      # ← 完成！コミットしたい
  modified:   dashboard.js  # ← まだ作業中...

# login.js だけをステージング
$ git add login.js

# 再度状態を確認
$ git status
Changes to be committed:
  modified:   login.js      # ← ステージング済み（コミットに含まれる）

Changes not staged for commit:
  modified:   dashboard.js  # ← まだステージングしていない（コミットに含まれない）

# コミット実行
$ git commit -m "Fix login feature"
# → login.js だけがコミットされる
# → dashboard.js は作業中のまま残る

このように、ステージングエリアを使えば「完成した部分だけ」を選んでコミットできます。作業中のファイルを巻き込む心配がありません。

3つの状態

Gitで管理されるファイルは、3つの状態を遷移します。

1. ワークツリー: 実際にファイルを編集する場所。エディタで開いているファイルはここにあります。

2. ステージングエリア: コミットする予定の変更を準備する場所。git addコマンドで変更をここに追加します。

3. リポジトリ: コミットされた変更が永続的に保存される場所。git commitコマンドでステージングエリアの内容がここに記録されます。

ステージングの4つの利点

1. 選択的コミット: 複数のファイルを変更しても、関連する変更だけを選んでコミットできる

2. 部分的ステージング: 1つのファイル内でも、特定の行だけをステージングできる（git add -p）

3. レビュー機会: コミット前に「何をコミットしようとしているか」を確認できる（git status、git diff --staged）

4. 作業の中断対応: 開発中に緊急のバグ修正が入っても、現在の作業を一時退避して別のコミットを作成できる

実際の流れ

# 1. ファイルを編集（ワークツリーで作業）
$ code feature.js  # VS Codeで開いて編集

# 2. 変更をステージング
$ git add feature.js

# 3. ステージングされた内容を確認
$ git status
Changes to be committed:
  modified:   feature.js

# 4. コミット
$ git commit -m "Add user authentication"

git statusの読み方

git statusはGitで最も頻繁に使うコマンドの一つです。出力の読み方を詳しく見てみましょう。

$ git status
On branch main                          # 現在のブランチ

Changes to be committed:                # 緑色で表示
  (use "git restore --staged <file>..." to unstage)
        modified:   completed.js        # → コミットに含まれる

Changes not staged for commit:          # 赤色で表示
  (use "git add <file>..." to update what will be committed)
        modified:   work-in-progress.js # → コミットに含まれない

Untracked files:                        # 赤色で表示
  (use "git add <file>..." to include in what will be committed)
        new-file.js                     # → Gitで追跡されていない

3つのセクションの意味:

コミット前には必ずgit statusを確認し、「緑色のセクションに意図したファイルがあるか」を確認する習慣をつけましょう。

2章7 まとめ もくじ

この章では、Gitの基本概念を学びました。リポジトリ、コミット、ブランチという3つの柱を理解することで、Gitがどのように動作するかがイメージできるようになったはずです。

この章で学んだこと

• リポジトリ: プロジェクトのファイルと変更履歴を保存する場所。.gitフォルダがその実体
• コミット: プロジェクトの状態を記録したスナップショット。「ボス戦前のセーブ」のようなもの
• ブランチ: コミットへのポインタ。ファイルのコピーではなく、非常に軽量
• HEAD: 現在いる場所を示すポインタ。「今ココ」マーカー
• ステージングエリア: コミットする変更を選んで準備する場所。部分的なコミットを可能にする
• 3つの領域: ワークツリー → ステージングエリア → リポジトリという流れで変更が記録される

理解度チェック

次章予告: 第3章では、Git、VS Codeなどの開発環境を整えます。実際にGitを使う準備を進めていきましょう。

本書の無料ダウンロードコンテンツ

本書の読者向けに、学習を加速する5つの特典を無料で提供しています。

• Gitコマンド完全リファレンス（約80コマンド、150以上のオプション）
• Bash/CLIコマンドチートシート（約100コマンド、250以上のオプション）
• シェルテクニック完全ガイド（パイプ・変数展開・スクリプト技法）
• Gitエラー解決完全ガイド（約60エラーの原因と対処法）
• Git Hooksサンプル（pre-commit、pre-push、commit-msg）

ダウンロードURL: https://alphaelements.co.jp/ja/books/why-git-vol1/

合言葉: UnlockGit2026

※ダウンロードには合言葉の入力が必要です