Git：コードのタイムマシン

💡 学習ガイド：この章は、Git を使ったことがない方に向けて書かれています。最初からコマンドを暗記させるのではなく、「Git があなたのどんな問題を解決してくれるのか」を先に理解し、その後コマンドと概念を順につなげていきます。読み終えると、ローカルコミット、ブランチの作成、GitHub へのプッシュができるようになります。

0. まず一つ質問：こんな悪夢を経験したことはありませんか？

シナリオ 1：バージョン地獄

論文やコードを書いていて、途中で間違いに気づき、3 日前のバージョンに戻りたい——でも見つかりません。

project_v1.zip
project_v2_revised.zip
project_v3_final.zip
project_v3_final_really_final.zip
project_v3_final_no_more_changes.zip

新しいコピーを保存するたびにハードディスクは散らかり、どのバージョンで何を変更したのか覚えられません。

シナリオ 2：コラボレーションの悪夢

あなたとチームメイトが同じファイルを同時に変更：

あなたは 10 行目を変更し、ログイン機能を追加した
チームメイトも 10 行目を変更し、バグを修正した
メールでコードを送り合い、マージ時に片方の変更がもう片方を上書きしてしまった
最終的にどのコードが正しいのか誰も分からない

シナリオ 3：「やり直し」ボタンがない

本番環境に新しいコードをデプロイしたらバグが発生。直前の安定バージョンに緊急ロールバックしたい——でも方法が分からず、慌ててバックアップを探すしかない。

Git はこの 3 つの問題を解決するために作られました。

Git はバージョン管理システム（Version Control System）です。その本質は：あなたの「セーブ」操作をすべて記録し、完全な歴史タイムラインを形成し、いつでも任意の歴史ポイントに戻れるようにすること。

Git は現代のソフトウェア開発において最も重要なツールの一つと言っても過言ではありません。ほぼすべての企業、すべてのオープンソースプロジェクトが使用しています。

1. Git と GitHub は同じものですか？

多くの初心者がこの 2 つを混同するので、まず明確にしましょう：

	Git	GitHub
何か	あなたのコンピュータ上で動くバージョン管理ツール	Git リポジトリをホストするウェブサイト（クラウド）
どこにあるか	あなたのローカルコンピュータ	インターネット上
単独で使えるか	✅ はい、ローカルの履歴のみ管理	❌ Git と一緒に使う必要がある
例え	あなたの手元の日記帳	日記を保存するクラウドストレージ

簡単に言うと：Git はツール、GitHub はホスティングサービス。 Word がツールで OneDrive がクラウドストレージであるのと同じで、両者は一緒に使いますが、同じものではありません。

GitHub の他に、GitLab、Gitee（中国）などの類似サービスがあります。

2. コア概念：3 つの領域

これは Git 全体で最も重要な設計です。この 3 つの領域を理解すれば、Git の魂を理解したことになります。

Git はファイルの状態を 3 つの層に分けます：

ワーキングディレクトリ（Working Directory） あなたの通常のフォルダです。見えている、編集中のすべてのファイルがここにあります。自由に変更でき、Git は何を変更したかを感知しますが、記録はしません。

ステージングエリア（Staging Area / Index） これは「コミット準備」の中継ステーションです。ワーキングディレクトリから保存したいファイルをステージングエリアに「入れる」ことができます——荷物を宅配便の箱に入れるようなもので、まだ発送していませんが、何を送るかは選んでいます。

リポジトリ（Repository） これは永久保存の歴史記録庫で、.git フォルダの中に隠れています。git commit を実行するたびに、ステージングエリアの内容がリポジトリに封印され、改ざん不可能な歴史記録が形成されます。

👇 試してみよう：コマンドボタンを順にクリックし、ファイルが 3 つの領域の間をどのように移動するか観察してください。

~/project (main)

# 你刚改了 3 个文件，现在演示 add → commit 流程

$ ▋

📝工作区Working Directory
你正在改的文件

Changes not staged for commit:

Mlogin.js未暂存

Mstyle.css未暂存

Mdebug.log未暂存

git add

📦暂存区Staging Area
准备这次提交的文件

Changes to be committed:

（空）

git commit

🗄️仓库Repository (.git)
永久保存的版本

已提交记录 (git log):

✓9f3e1b2init: 项目初始化HEAD

💡 点击下方命令按钮，按顺序执行。观察右侧三区里文件如何随命令移动。

なぜ「2 ステップ」（add + commit）なのか？

多くの初心者が疑問に思います：なぜワンクリックで保存できないのか？なぜ先に add してから commit しなければならないのか？

現実の開発では、すべての変更を一緒にコミットしたくないことがよくあるからです。

例えば：今日あなたは 5 つのファイルを変更しました：

login.js：ログイン機能を完成させた（コミットしたい）
style.css：ログインページのスタイルを調整した（コミットしたい）
debug.log：一時的なデバッグ出力（コミットしたくない）
experiment.js：テスト中の新機能、まだ未完成（コミットしたくない）
todo.txt：個人的なメモ（コミットしたくない）

ステージングエリアがなければ、5 つのファイルをすべてコミットするか（コミット履歴が乱雑になる）、どれもコミットしないかのどちらかになります。

ステージングエリアがあれば、精密に制御できます：git add login.js style.css——この 2 つのファイルだけを宅配便の箱に入れ、commit します。このコミットは「ログイン機能の完成」と明確に記録されます。

3. 初めての Git：初期化と基本ワークフロー

3.1 インストールと初期化

Git をインストールした後（macOS には標準搭載、Windows は git-scm.com からダウンロード）、ターミナルを開いてプロジェクトフォルダに移動します：

bash

# 現在のフォルダで Git リポジトリを初期化
git init

# Git は非表示の .git フォルダを作成し、すべての履歴がそこに保存されます
# 出力：Initialized empty Git repository in .../your-project/.git/

初めて使用する際、Git にあなたが誰かを伝える必要があります（この情報は各コミットに添付されます）：

bash

git config --global user.name "あなたの名前"
git config --global user.email "あなたのメールアドレス"

3.2 日常のワークフロー：3 ステップのセーブ

初期化後、日常開発の 90% はこの 3 つのステップを繰り返すだけです：

ステップ 1：ステータスの確認

bash

git status

これが最もよく使うコマンドです。以下の情報を表示します：

どのブランチにいるか
どのファイルが変更されたか（赤 = 未ステージング）
どのファイルがステージングエリアにあるか（緑 = ステージング済み、コミット待ち）

ステップ 2：ファイルをステージングエリアに入れる

bash

# 単一ファイルの追加
git add login.js

# 複数ファイルの追加
git add login.js style.css

# 現在のフォルダのすべての変更ファイルを追加（. は「すべて」を意味する）
git add .

⚠️ 初心者によある落とし穴：git add . は非常に便利ですが、コミットしたくない一時ファイルも含めてすべての変更が追加されます。正確に add する習慣を身につけるか、追跡したくないファイルを .gitignore で除外しましょう（後で説明します）。

ステップ 3：コミットしてメッセージを書く

bash

git commit -m "feat: ユーザーログイン機能を追加"

-m の後の引用符内のテキストはコミットメッセージと呼ばれます。これは将来の自分とチームメイトのために書くものです。意味のある内容にしましょう。

3.3 プロフェッショナルなコミットメッセージの書き方

bash

# ❌ 悪い例——見ても何をしたのか分からない
git commit -m "update"
git commit -m "fix"
git commit -m "いくつか変更した"

# ✅ 良い例：タイプ + コロン + 一文の説明
git commit -m "feat: ユーザーログイン機能を追加"
git commit -m "fix: iOS Safari でのホームページ白画面問題を修正"
git commit -m "docs: README のデプロイ手順を更新"
git commit -m "refactor: UserService を独立モジュールに分割"
git commit -m "style: コードのインデントを 2 スペースに統一"

一般的なプレフィックスの意味：

プレフィックス	意味
`feat:`	新機能（feature）
`fix:`	バグ修正
`docs:`	ドキュメントの変更
`style:`	コードフォーマット（機能に影響なし）
`refactor:`	コードリファクタリング（機能は同じ、構造の改善）
`chore:`	ビルド、ツール、依存関係関連
`test:`	テスト関連

この習慣を身につければ、数ヶ月後に履歴を見返したとき、各コミットで何をしたかが一目で分かります。これはチーム開発で特に重要です。

3.4 履歴の確認**

bash

# 詳細フォーマット（各コミットの完全な情報）
git log

# 簡潔フォーマット（1 行に 1 件、日常使用に推奨）
git log --oneline

# 出力例：
# a1b2c3d (HEAD -> main) feat: ユーザーログイン機能を追加
# 9f3e1b2 init: プロジェクト初期化

4. パラレルワールド：ブランチ（Branch）

ブランチは Git の最も強力な——そして初心者を最も困惑させる——機能です。しかし理解すれば、その設計が非常に洗練されていることが分かります。

4.1 ブランチとは何か？「パラレルワールド」で理解する

RPG ゲームで重大な選択肢に直面していると想像してください：

選択肢 A：最終ボスに挑戦する（新機能の開発）
選択肢 B：現状を安定させる（メインストーリーはそのまま）

メインセーブデータで選択肢 A を選んで失敗したら、ゲームの進行全体がダメになります。

しかしセーブデータをコピーして、そのコピーでボスに挑戦したら：

勝った？コピーの成果をメインセーブに統合する
負けた？メインセーブには全く影響なし——コピーを削除してやり直す

Git ブランチはこの「コピーセーブ」の仕組みです。

Git では、main（または master）ブランチがあなたの「メインセーブ」で、常に安定して使用可能な状態を保ちます。新機能を開発したいとき、main から新しいブランチを作成し、そこで開発・テストし、完了したら main にマージします。

4.2 ブランチの可視化デモ

👇 試してみよう：コマンドボタンを順にクリックし、下のブランチグラフがどのように分岐し、伸び、最終的にマージされるか観察してください。HEAD ラベルの位置変化に特に注目してください——それは常に「今どこにいるか」を示しています。

~/project (main)

# main 分支上已有 2 次提交，按步骤演示分支操作

$ ▋

main 主分支HEAD 你当前所在位置

💡 👆 依次点击上方命令按钮，观察下方分支图的变化

4.3 ブランチ操作の詳細

ブランチを作成して切り替える：

bash

# 方法 1：先に作成、次に切り替え（2 ステップ）
git branch feature-login      # ブランチを作成
git checkout feature-login    # 切り替え

# 方法 2：一発で（推奨）
git checkout -b feature-login

# 出力：Switched to a new branch 'feature-login'

ブランチを作成すると、コマンドプロンプトに現在のブランチ名が表示されます：

user@mac ~/project (feature-login) $

すべてのブランチを確認：

bash

git branch

# 出力（* は現在のブランチを示す）：
# * feature-login
#   main

ブランチ上で通常通り開発：

bash

# feature-login ブランチで、コードを変更、add、commit——いつもと全く同じ
git add login.js
git commit -m "feat: ログインフォームの HTML 構造を追加"

git add login.js api.js
git commit -m "feat: ログイン API 連携を完了"

これらのコミットは feature-login ブランチにのみ存在し、main ブランチはあなたが何をしたか全く知りません。

メインブランチに戻ってマージ：

bash

# main に戻る
git checkout main

# feature-login のすべての変更をマージ
git merge feature-login

# マージ完了後、ブランチを削除（オプション）
git branch -d feature-login

4.4 いつブランチを作るべきか？

シナリオ	推奨	理由
新機能の開発	✅ ブランチを作成	機能が完成するまでメインラインに影響しない；いつでも放棄可能
本番環境の緊急バグ修正	✅ main から `hotfix-xxx` ブランチを作成	修正後すぐにマージしてデプロイ、未完成の機能を持ち込まない
チームメイトとの並行開発	✅ 各自がブランチを作成	干渉なし；完了後 Pull Request で一括マージ
タイプミスの修正のみ	❌ main で直接修正	リスクが非常に低く、ブランチを作る必要なし

4.5 チームでよく使われるブランチ戦略

実際のプロジェクトでは、チームは通常ブランチの命名規則と用途について合意します：

ブランチ名	用途	特徴
`main` / `master`	本番環境の安定したコード	テスト済みのコードのみ受け入れ；直接プッシュ不可
`dev` / `develop`	日常的な統合ブランチ	すべてのフィーチャーブランチはここにマージ；テスト通過後に main へ
`feature/xxx`	特定機能の開発	例：`feature/user-login`；完了後 dev にマージ
`hotfix/xxx`	緊急修正	main から作成；修正後 main と dev に直接マージ

5. チームメイトとの協力：リモートリポジトリ

ここまで学んだことはすべてローカルの Git 操作です——すべての履歴はあなたのコンピュータに保存されています。チームメイトとコードを共有するには、リモートリポジトリ、つまり GitHub や GitLab のようなクラウドストレージが必要です。

5.1 リモートリポジトリの仕組み

リモートリポジトリはチームの「共有セーブデータ」と考えられます：

各人がローカルでコードを書き、コミットする
完了したら push（アップロード）してリモートリポジトリに送る
チームメイトは pull（ダウンロード）してリモートリポジトリの最新内容をローカルに取得
これで全員のコードが同期される

👇 試してみよう：コマンドを順にクリックし、リモートリポジトリの関連付けからプッシュ、チームメイトの更新のプルまでの完全な流れを体験してください。

~/project (main)

# 本地 2 次提交，还没关联远程仓库

$ ▋

💻本地仓库~/project

9f3e1b2init: 初始化项目

c4d8a31feat: 首页布局

↑ 2 个未推送

push →

← pull

☁️远程仓库github.com/you/project

（空）

💡 点击下方命令按钮，按顺序执行

5.2 初めてプロジェクトを GitHub にプッシュする

ステップ 1：GitHub で新しいリポジトリを作成（右上の + をクリック → New repository）。初期化オプションにはチェックを入れないでください。

ステップ 2：ローカルターミナルに戻り、リモートリポジトリを関連付け：

bash

# ローカルリポジトリと GitHub のリポジトリを関連付ける
# "origin" はリモートリポジトリのエイリアスで、慣例的な名前（変更可能だが、その必要はない）
git remote add origin https://github.com/your-username/your-repo.git

# 関連付けの成功を確認
git remote -v
# 出力：
# origin  https://github.com/your-username/your-repo.git (fetch)
# origin  https://github.com/your-username/your-repo.git (push)

ステップ 3：ローカルの内容をリモートにプッシュ：

bash

# 初回プッシュ。-u は「今後の git push で、デフォルトで origin の main ブランチにプッシュする」ことを意味する
git push -u origin main

# 以降のプッシュはこれだけで OK：
git push

5.3 日常的なコラボレーションコマンド

プッシュ（自分の変更をチームメイトに見せる）：

bash

git push

プル（チームメイトの変更を同期）：

bash

git pull

git pull は実際には 2 つのコマンドの組み合わせです：

git fetch：リモートリポジトリから最新のコミットをダウンロード
git merge：ダウンロードした内容を現在のブランチにマージ

初めて GitHub から他人のプロジェクトを取得：

bash

# リモートリポジトリ全体をローカルにコピー（1 回だけ実行）
git clone https://github.com/someone/some-project.git

# clone は自動的にリモートとの関連付けを設定するので、その後は push/pull だけで OK

5.4 push と pull の方向

あなたのコンピュータ（ローカルリポジトリ）  ←→  GitHub（リモートリポジトリ）

git push：  ローカル → リモート   （自分の変更をアップロードしてチームメイトに共有）
git pull：  リモート → ローカル   （チームメイトの変更をダウンロード）
git clone： リモート → ローカル   （初回の完全コピー）

ベストプラクティス：毎日作業を始める前に git pull して最新コードを取得；作業終了時や機能完成後に git push して、迅速にバックアップし、チームメイトに進捗を共有。

6. 応用：コンフリクトの解決

コンフリクトはコラボレーションにおいて避けられないものですが、それほど怖くはありません。

6.1 コンフリクトはどうやって発生するのか？

あなたとチームメイトが同じファイルの同じ行を同時に変更した場合、マージ時に Git はどちらのバージョンを使うべきか判断できず、コンフリクトが発生します。

例えば：

あなたが login.js の 5 行目に const timeout = 3000 と書いた
チームメイトが同じ行に同時に const timeout = 5000 と書いた
git pull や git merge の際、Git はこの矛盾を検出し、「一時停止」して知らせます：どちらを使うべきか分からないので、あなたが決めてください。

6.2 コンフリクトファイルはどのように見えるか？

Git はコンフリクト箇所に特別なマーカーを挿入します：

javascript

function login() {
  const url = '/api/login'

 <<<<<<< HEAD
  const timeout = 3000   // あなたのバージョン
 =======
  const timeout = 5000   // チームメイトのバージョン
 >>>>>>> feature/update-timeout

  return fetch(url, { timeout })
}

<<<<<<< HEAD から ======= の間：あなたの現在のブランチの内容
======= から >>>>>>> xxx の間：マージされる内容

6.3 コンフリクトの解決方法

ステップ 1：コンフリクトファイルを開き、すべての <<<<<<< マーカーを見つける（VS Code などのエディタは通常自動的にハイライトします）

ステップ 2：どのコードを残すか決定し、ファイルを手動で編集し、すべてのマーカー（<<<<<<<、=======、>>>>>>>）を削除する。

例えば、5000（チームメイトのバージョン）を採用すると決めた場合：

javascript

function login() {
  const url = '/api/login'
  const timeout = 5000   // チームメイトの変更を採用
  return fetch(url, { timeout })
}

ステップ 3：再度コミット

bash

# コンフリクト解決済みとしてマーク
git add login.js

# マージコミットを完了（Git がマージコミットメッセージを自動生成）
git commit

6.4 コンフリクトを減らす良い習慣

こまめに pull する：作業開始前に最新コードを同期し、「大幅に遅れる」状況を減らす
小さく頻繁にコミットする：1 週間分のコードをまとめてコミットしない。小さなコミットを頻繁に行うほど、コンフリクトの発見と解決が容易
ブランチの分離：異なる機能には異なるブランチを使用し、同じ行のコードを巡る競合を減らす
コミュニケーション：共通ファイル（config.js など）を変更する前に、チームメイトに一声かける

7. よく使うコマンド早見表

把这张表存起来，遇到忘了的命令随时查：

使用频率

命令（可左右滑动查看）

8. 実践：チームプロジェクトに参加する完全なワークフロー

新しいチームやプロジェクトに参加した際の標準的な操作フローです。そのまま使えます：

bash

# ① 初日：プロジェクトをローカルに clone（1 回だけ）
git clone https://github.com/team/project.git
cd project

# ② 毎日の作業開始時：最新コードを pull して、自分のコードを最新に保つ
git pull origin main

# ③ 自分のフィーチャーブランチを作成（main を直接変更しない）
git checkout -b feature/user-profile

# ④ 通常の開発...コードを書く...

# ⑤ 小さな機能単位で完了したら、すぐにコミット（ため込まない）
git add src/UserProfile.vue
git commit -m "feat: ユーザーアバターアップロード機能を完了"

git add src/UserProfile.vue src/api/user.js
git commit -m "feat: ユーザープロフィール編集 API を完了"

# ⑥ 自分のブランチをリモートにプッシュして、チームメイトが見えるようにする
git push origin feature/user-profile

# ⑦ GitHub で Pull Request（PR）を作成し、main へのマージをリクエスト
# （このステップは GitHub のウェブページで操作）

# ⑧ チームメイトの Code Review を待ち、フィードバックに基づいて修正、コミット + プッシュを継続

# ⑨ PR がマージされたら、main に戻り、ローカルを更新、フィーチャーブランチを削除
git checkout main
git pull
git branch -d feature/user-profile

9. .gitignore：どのファイルを追跡すべきでないか？

いくつかのファイルは Git リポジトリにコミットしたくないものです：

node_modules/：依存パッケージ、サイズが巨大、npm install で再生成可能
.env：環境変数ファイル、データベースパスワードや API キーが含まれる可能性——公開リポジトリに絶対にアップロードしてはいけない
*.log：ログファイル
.DS_Store：macOS が自動生成する隠しファイル
dist/、build/：ビルド成果物、再ビルド可能

プロジェクトのルートディレクトリに .gitignore ファイルを作成し、追跡したくないファイルのルールを記述します：

gitignore

# 依存パッケージ
node_modules/

# 環境変数（重要！パスワードはコミット不可）
.env
.env.local

# ビルド成果物
dist/
build/

# システムファイル
.DS_Store
Thumbs.db

# ログ
*.log

GitHub には各言語やフレームワークの .gitignore テンプレートがあります：github.com/github/gitignore

用語早見表

用語	英語	説明
リポジトリ	Repository (Repo)	プロジェクトのすべてのバージョン履歴を保存するデータベース、`.git` フォルダ内にある
コミット	Commit	完全なバージョン記録。ゲームのセーブポイントのようなもので、説明とタイムスタンプが付く
ブランチ	Branch	独立した開発ライン。パラレルなタイムラインのように互いに影響しない
マージ	Merge	一方のブランチの変更をもう一方のブランチに統合する
コンフリクト	Conflict	同じ行のコードが複数人によって変更され、Git がどちらのバージョンを使うべきか判断できず、手動解決が必要
ステージ	Stage / Index	変更を「コミット準備完了」リストに入れる操作
リモート	Remote	クラウドのリポジトリコピー（GitHub / GitLab / Gitee）
クローン	Clone	リモートリポジトリ全体をローカルにコピーする
プッシュ	Push	ローカルのコミットをリモートリポジトリにアップロードする
プル	Pull	リモートの最新内容をダウンロードし、ローカルにマージする
HEAD	HEAD	現在のブランチ/コミットへのポインタ。「今どこにいるか」を示す
origin	origin	リモートリポジトリのデフォルトエイリアス（慣例的な名前）
stash	Stash	まだコミットしていない変更を一時保存する。タスク切り替え時に使用
PR / MR	Pull Request / Merge Request	自分のブランチをメインブランチにマージするリクエスト。通常チームメイトのレビューが必要

Git：コードのタイムマシン ​

0. まず一つ質問：こんな悪夢を経験したことはありませんか？ ​

1. Git と GitHub は同じものですか？ ​

2. コア概念：3 つの領域 ​

なぜ「2 ステップ」（add + commit）なのか？ ​

3. 初めての Git：初期化と基本ワークフロー ​

3.1 インストールと初期化 ​

3.2 日常のワークフロー：3 ステップのセーブ ​

3.3 プロフェッショナルなコミットメッセージの書き方 ​

3.4 履歴の確認** ​

4. パラレルワールド：ブランチ（Branch） ​

4.1 ブランチとは何か？「パラレルワールド」で理解する ​

4.2 ブランチの可視化デモ ​

4.3 ブランチ操作の詳細 ​

4.4 いつブランチを作るべきか？ ​

4.5 チームでよく使われるブランチ戦略 ​

5. チームメイトとの協力：リモートリポジトリ ​

5.1 リモートリポジトリの仕組み ​

5.2 初めてプロジェクトを GitHub にプッシュする ​

5.3 日常的なコラボレーションコマンド ​

5.4 push と pull の方向 ​

6. 応用：コンフリクトの解決 ​

6.1 コンフリクトはどうやって発生するのか？ ​

6.2 コンフリクトファイルはどのように見えるか？ ​

6.3 コンフリクトの解決方法 ​

6.4 コンフリクトを減らす良い習慣 ​

7. よく使うコマンド早見表 ​

8. 実践：チームプロジェクトに参加する完全なワークフロー ​

9. .gitignore：どのファイルを追跡すべきでないか？ ​

用語早見表 ​

Git：コードのタイムマシン

0. まず一つ質問：こんな悪夢を経験したことはありませんか？

1. Git と GitHub は同じものですか？

2. コア概念：3 つの領域

なぜ「2 ステップ」（add + commit）なのか？

3. 初めての Git：初期化と基本ワークフロー

3.1 インストールと初期化

3.2 日常のワークフロー：3 ステップのセーブ

3.3 プロフェッショナルなコミットメッセージの書き方

3.4 履歴の確認**

4. パラレルワールド：ブランチ（Branch）

4.1 ブランチとは何か？「パラレルワールド」で理解する

4.2 ブランチの可視化デモ

4.3 ブランチ操作の詳細

4.4 いつブランチを作るべきか？

4.5 チームでよく使われるブランチ戦略

5. チームメイトとの協力：リモートリポジトリ

5.1 リモートリポジトリの仕組み

5.2 初めてプロジェクトを GitHub にプッシュする

5.3 日常的なコラボレーションコマンド

5.4 push と pull の方向

6. 応用：コンフリクトの解決

6.1 コンフリクトはどうやって発生するのか？

6.2 コンフリクトファイルはどのように見えるか？

6.3 コンフリクトの解決方法

6.4 コンフリクトを減らす良い習慣

7. よく使うコマンド早見表

8. 実践：チームプロジェクトに参加する完全なワークフロー

9. .gitignore：どのファイルを追跡すべきでないか？

用語早見表