1.2.1 Git の基礎概念

残す証拠

このページを終えたら、この evidence card を残します。

リポジトリ状態

操作前後の git status

操作

init、add、commit、branch、merge、remote、pull、またはpushコマンドを使用

履歴

何が変わったかを示す git log またはブランチグラフ

失敗確認

未追跡ファイル、誤ったブランチ、マージ衝突、またはリモート/認証の問題

期待される成果

別の学習者が安全に再実行できる、きれいな Git の trace

この節の位置づけ

この節ではまず、なぜコードにバージョン管理が必要なのかを理解します。「ファイル名が増えすぎてわからない」「壊してしまって元に戻せない」「複数人での共同作業が難しい」といった実際の悩みから出発して、リポジトリ、ステージングエリア、コミット、ブランチの基本を身につけます。

学習目標

• なぜバージョン管理が必要なのかを理解する（実際の困りごとを通して）
• 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 のとても独特な設計です。ステージングエリアは「コミットする準備」をする中間地点です。

引っ越しにたとえると、

1. 部屋の中にたくさん物がある（作業ディレクトリ —— 今まさに編集しているファイル）
2. その中から運ぶ物を選んで玄関に置く（ステージングエリア —— 選んで、記録する準備ができたファイル）
3. 引っ越し業者が来て、玄関の物をトラックに積んで運ぶ（コミット —— 変更を正式に記録する）

# 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 の 3 つの状態の流れを説明できることです。

最小証拠は次の通りです。

1. 最初の commit 後、git log --oneline に初期 commit がある。
2. 2 回目の変更後、git diff が具体的な差分を示す。
3. git add 後、git status で staged 状態を説明できる。
4. 2 回目の commit 後、履歴に 2 件の commit がある。
5. 各 commit 後、git status が clean に戻る。

modified や untracked が残る場合は、branch に進む前に working tree -> staging area -> committed history の流れを確認します。

まとめ

概念	一言でいうと	たとえ
リポジトリ	Git に管理されているプロジェクトフォルダ	「やり直し履歴」がある魔法のノート
ステージングエリア	コミット準備中の中間地点	引っ越しで玄関に置いて積み込み待ちの物
コミット	1回分の正式な版記録	ゲームのセーブ
ブランチ	独立した開発ライン	平行世界
作業ディレクトリ	いま編集しているファイル	いま書いている下書き

核心理解

Git の基本の流れはたった3つです。ファイルを変更する → add（ステージする） → commit（コミットする）。この先の Git 操作は、すべてこの土台の上にあります。