1.2.1 Git の基礎概念
この節の位置づけ
この節ではまず、なぜコードにバージョン管理が必要なのかを理解します。「ファイル名が増えすぎてわからない」「壊してしまって元に戻せない」「複数人での共同作業が難しい」といった実際の悩みから出発して、リポジトリ、ステージングエリア、コミット、ブランチの基本を身につけます。
学習目標
- なぜバージョン管理が必要なのかを理解する（実際の困りごとを通して）
- Git の4つの核心概念を身につける：リポジトリ、ステージングエリア、コミット、ブランチ
- Git のインストールと初期設定を完了する
Git がない世界
Git を学ぶ前に、Git がないとき開発者はどのようにコードを管理していたのかを見てみましょう。
悩み1：ファイル名地獄
AI モデルの学習スクリプトを書いて、何度も修正しては保存していきます。
train.py
train_v2.py
train_v2_final.py
train_v2_final_ほんとうの最終版.py
train_v2_final_ほんとうの最終版_bug修正.py
train_v2_final_ほんとうの最終版_bug修正_上司がもう少し直してと言った.py
1週間後に「最初の bug 修正の前の版」に戻りたくなったら、いったいどのファイルでしょうか？
悩み2：壊したら戻れない
意気込んで model.py をリファクタリングし、200行もコードを変えました。実行すると——エラー。さらに直すと——もっとエラー。元の状態に戻したいのに、すでに何度も Ctrl+S で保存してしまっていて、戻れません。
悩み3：共同作業は大混乱
あなたと同僚が同じファイルを同時に編集しています。あなたは前半を、相手は後半を変更しました。それぞれ保存したあと、微信でファイルを送り合います。誰がまとめるのでしょう？ どうやってまとめるのでしょう？ 相手の変更を上書きしてしまったらどうしますか？
Git は、この3つの問題を解決します。
| 悩み | Git はどう解決するか |
|---|---|
| ファイル名地獄 | 変更のたびに自動で版を記録するので、手動で名前を変える必要がない |
| 壊したら戻れない | いつでも過去の好きな版に戻せる |
| 共同作業が難しい | それぞれが自分のブランチで作業し、最後に自動で統合できる |
Git とは？
一言で言うと、Git はコードのバージョン管理ツールです。コードの変更を1つ1つ記録してくれるので、履歴の確認、版の巻き戻し、他人との共同作業がいつでもできます。
重要なポイントは次のとおりです。
- Git は無料のオープンソースです
- Git はローカルで使えるツールです。ネットにつながっていなくても使えます（GitHub は Git のオンラインホスティングサービスであり、Git そのものではありません）
- Git は業界標準です。ほとんどすべてのソフトウェア企業、ほとんどすべてのオープンソースプロジェクトが Git を使っています
- Git は Linux の生みの親 Linus Torvalds によって 2005 年に作られました
Git の4つの核心概念
Git を賢い保存システムだと考えてみましょう。あなたが大きなゲーム（コードを書くこと）を遊んでいるとき、Git がいつでもセーブとロードを手伝ってくれます。
概念1：リポジトリ（Repository）
リポジトリ = Git に管理されているプロジェクトフォルダです。
普通のフォルダと Git リポジトリの違いは、ふつうのノートと「すべての変更履歴」が残る魔法のノートの違いのようなものです。
# ある普通のフォルダを Git リポジトリにする
cd my-project
git init
git init を実行すると、フォルダの中に隠しディレクトリ .git が追加されます。ここが Git がすべての版情報を保存する場所です。中を開く必要はありません。そこにあると知っていれば十分です。
概念2：ステージングエリア（Staging Area）
これは Git のとても独特な設計です。ステージングエリアは「コミットする準備」をする中間地点です。
引っ越しにたとえると、
- 部屋の中にたくさん物がある（作業ディレクトリ —— 今まさに編集しているファイル）
- その中から運ぶ物を選んで玄関に置く（ステージングエリア —— 選んで、記録する準備ができたファイル）
- 引っ越し業者が来て、玄関の物をトラックに積んで運ぶ（コミット —— 変更を正式に記録する）
# 3つのファイルを変更した：model.py、train.py、notes.txt
# model.py と train.py だけを「玄関」（ステージングエリア）に置く
git add model.py train.py
# notes.txt はまだ「部屋の中」に残す。今回はコミットしない
なぜステージングエリアが必要なのでしょうか？ 5つのファイルを同時に変更していても、今回記録したいのはそのうち2つだけ、ということがあるからです。ステージングエリアがあることで、毎回のコミットに含める変更を正確にコントロールできます。
概念3：コミット（Commit）
コミット = 1回分の正式な版記録です。ゲームのセーブポイントのようなものです。
各コミットには次の情報が含まれます。
- どのファイルが変更されたか
- 具体的に何が変わったか（どの行に何を追加したか、何を削除したか）
- いつコミットしたか
- 誰がコミットしたか
- どんな内容かを説明するメッセージ
git commit -m "モデル学習時の学習率が大きすぎる bug を修正"
-m の後ろの文字列はコミットメッセージで、今回の変更内容を説明します。よいコミットメッセージは、自分以外の人（未来の自分も含む）が見ても、何を変えたのかすぐわかるものです。
プロジェクトのコミット履歴は、たとえば次のようになります。
コミット #5: "データ拡張機能を追加" ← 最新
コミット #4: "モデル学習時の学習率が大きすぎる bug を修正"
コミット #3: "CNN モデル定義を追加"
コミット #2: "データ読み込みモジュールを完成"
コミット #1: "プロジェクト初期化、README を追加" ← 最初
いつでも好きなコミットに戻れます。ゲームのセーブデータを読み込むようなものです。
概念4：ブランチ（Branch）
ブランチ = 独立した開発ラインです。平行世界のようなものです。
あなたのプロジェクトを1本のメイン道路（main ブランチ）だと想像してください。新しい機能（たとえばモデル構造を変える）を試したいけれど、成功するかはまだわかりません。メインの道路をいじりたくはありません。壊れたら困るからです。
そんなときは、メイン道路から新しい道（新しいブランチ）を分岐させます。その道で自由に試せます。うまくいったらメイン道路に戻して統合し、失敗したらその道を削除するだけです。メイン道路にはまったく影響しません。
main ブランチ: ● ─── ● ─── ● ─── ● ─── ● (安定したコード)
\ ↗
feature ブランチ: ● ─── ● (新機能を試す)
ブランチについては後の章で詳しく説明します。今は存在だけ覚えておけば大丈夫です。
完全な作業フロー（まず全体像を見る）
Git でコードを管理する一連の流れは次のとおりです。
ファイルを変更する → 記録するファイルを選ぶ（add） → 正式に記録する（commit） → クラウドへ送る（push）
作業ディレクトリ ステージングエリア ローカルリポジトリ リモートリポジトリ(GitHub)
具体例を見てみましょう。
# 1. 新しいモデルファイルを書いた
# （このときファイルは「作業ディレクトリ」にあり、Git は変更を知っているが、まだ記録していない）
# 2. ステージングエリアに入れる
git add model.py
# 3. 正式にコミットする（この変更を記録する）
git commit -m "ResNet モデル定義を追加"
# 4. GitHub に push する（クラウド側にもこの記録を置く）
git push
Git のインストール
macOS
# 方法1：Homebrew を使う（おすすめ）
brew install git
# 方法2：ターミナルで git を直接入力すると、macOS が Xcode Command Line Tools のインストールを案内する
git --version
Ubuntu / Debian
sudo apt update
sudo apt install git
Windows
# winget を使う
winget install Git.Git
# インストール後にターミナルを再起動して、確認する
git --version
また、git-scm.com からインストーラーをダウンロードすることもできます。インストール中は基本的にデフォルトのままで大丈夫です。
インストール確認
git --version
# 例: git version 2.43.0
バージョン番号が表示されれば、インストール成功です。
初期設定
Git をインストールしたら、まず「あなたが誰か」を Git に伝える必要があります。この情報は、今後のコミット記録に表示されます。
# 名前を設定する（英語推奨。GitHub に表示されます）
git config --global user.name "Zhang San"
# メールアドレスを設定する（GitHub 登録時と同じものがおすすめ）
git config --global user.email "[email protected]"
# デフォルトのブランチ名を main に設定する（新しい Git の標準）
git config --global init.defaultBranch main
# 設定を確認する
git config --list
--global について--global は「グローバル設定」を意味します。あなたのパソコン上のすべての Git リポジトリに反映されます。もしあるプロジェクトだけ別の設定が必要なら（たとえば会社のプロジェクトでは会社のメールを使うなど）、そのプロジェクト内では --global を付けずに個別に設定できます。
ちょっと試してみよう
では、最初の Git リポジトリを作って、全体の流れを体験してみましょう。
# 新しいプロジェクトを作る
mkdir my-first-repo
cd my-first-repo
# Git リポジトリを初期化する
git init
# 出力: Initialized empty Git repository in .../my-first-repo/.git/
# ファイルを作る
echo "# 私の最初の Git リポジトリ" > README.md
echo "print('Hello Git!')" > hello.py
# 状態を確認する——Git はどのファイルに変更があるか教えてくれる
git status
# README.md と hello.py が赤色（未追跡ファイル）で表示される
# ファイルをステージングエリアに追加する
git add .
# "." は現在のディレクトリ内のすべてのファイルを意味する
# もう一度状態を確認する——ファイルが緑色（ステージ済み、コミット準備完了）になる
git status
# コミットする！
git commit -m "プロジェクト初期化：README と hello.py を追加"
# 出力: [main (root-commit) abc1234] プロジェクト初期化：README と hello.py を追加
# コミット履歴を見る
git log --oneline
# 出力: abc1234 プロジェクト初期化：README と hello.py を追加
おめでとうございます。これで初めての Git コミットが完了しました。
次に、ファイルを少し変更して、もう1回コミットしてみましょう。
# hello.py を変更する
echo "print('Hello Git! I am learning AI.')" > hello.py
# 何が変わったかを見る
git diff
# 変更内容が赤/緑でハイライト表示される
# 追加してコミットする
git add hello.py
git commit -m "挨拶文を更新する"
# 履歴を確認する——これで2件の記録がある
git log --oneline
# 出力:
# def5678 挨拶文を更新する
# abc1234 プロジェクト初期化：README と hello.py を追加
2回コミットすれば、2つのセーブポイントができたことになります。いつでもどちらにも戻れます。
まとめ
| 概念 | 一言でいうと | たとえ |
|---|---|---|
| リポジトリ | Git に管理されているプロジェクトフォルダ | 「やり直し履歴」がある魔法のノート |
| ステージングエリア | コミット準備中の中間地点 | 引っ越しで玄関に置いて積み込み待ちの物 |
| コミット | 1回分の正式な版記録 | ゲームのセーブ |
| ブランチ | 独立した開発ライン | 平行世界 |
| 作業ディレクトリ | いま編集しているファイル | いま書いている下書き |
Git の基本の流れはたった3つです。ファイルを変更する → add（ステージする） → commit（コミットする）。この先の Git 操作は、すべてこの土台の上にあります。