BEGINNER'S GUIDE

Git & GitHub 入門

AIと一緒に学ぶバージョン管理

Claude がGitを使う理由も解説

→ キーで次へ

この編の全体像

ゴール: ひとりでGitを使ってコードを管理し、GitHubにpushできるようになる

Part 1

Gitの基礎知識

Gitとは何か / なぜ必要か / インストール&初期設定

→ 「何を学ぶのか」を理解する

Part 2

基本操作を覚える

3つのエリア / add・commit / status・diff / push / ブランチ・PR

→ 手を動かしてコマンドを体験する

Part 3

個人開発の流れ

プロジェクト初期化 → 開発 → GitHub公開 → ブランチ → マージ

→ 実際の開発サイクルを一気通貫で見る

Part 4

AIとGit

Claudeのワークフロー / コミット作法 / テスト / PR作成

→ AIがGitをどう使うか知る

Part 5

トラブルシューティング

コンフリクト / push拒否 / reset事故 / 秘密情報漏洩 / reflog

→ 困ったときの対処法を知る

Part 6

設定と管理

.gitignore / コマンドまとめ / リファレンス

→ きれいなリポジトリを維持する

Gitとは？

WITHOUT GIT

        report_final.docx

        report_final2.docx

        report_final_本当にfinal.docx

        report_final_提出用v3.docx

        report_本当に最終版.docx

        😱 どれが最新？

WITH GIT

        report.docx

        ├─ commit 1: 初稿作成

        ├─ commit 2: 図を追加

        ├─ commit 3: レビュー反映

        └─ commit 4: 最終修正

        ✓ 全ての履歴が残る！

Gitはバージョン管理システム。ファイルの変更履歴を全て記録し、いつでも過去の状態に戻れる。

なぜGitが必要なのか？

🕐

履歴管理

いつ・誰が・何を変えたか全て記録。いつでも過去に戻れる。

👥

チーム開発

複数人が同時に同じプロジェクトを編集。変更を統合できる。

🔀

ブランチ

本番を壊さず新機能を試せる。安全な実験場。

☁️

バックアップ

GitHubにコードを保存。PCが壊れても安心。

Gitの用語を知ろう

まずは言葉の意味を押さえよう

リポジトリ（Repository）

プロジェクトの「保管庫」。ファイルと全変更履歴がまとめて管理される場所。
git init で作成する。

ローカル / リモート

ローカル = 自分のPC上のリポジトリ
リモート = GitHub上のリポジトリ
この2つを同期して使う。

クローン（Clone）

リモートのリポジトリを丸ごとコピーして、自分のPCに持ってくること。
git clone URL

コミット（Commit）

変更を「記録」すること。ゲームのセーブポイントのようなもの。
git commit -m "メッセージ"

プッシュ（Push）

ローカルのcommitをリモートに送ること。「アップロード」に近い。
git push origin main

プル（Pull）

リモートの最新の変更をローカルに取得すること。「ダウンロード＋統合」。
git pull origin main

ローカルとリモートの関係

2つのリポジトリを行き来するイメージ

LOCAL（自分のPC）

ローカルリポジトリ

・コードを編集する場所

・git add / git commit

・オフラインでも作業可能

git push →

← git pull

← git clone

REMOTE（GitHub）

リモートリポジトリ

・コードのバックアップ

・チームで共有

・GitHub Pagesで公開

clone = 最初に一度だけ。リモートをコピーしてローカルに作る

push = ローカル → リモートに送る（自分の変更を共有）

pull = リモート → ローカルに取る（他人の変更を取得）

環境構築 (1/2) — インストール

1. Gitのインストール

Mac

brew install git

または Xcode Command Line Tools:
xcode-select --install

Windows

winget install Git.Git

またはgit-scm.comからDL
Git Bashも一緒に入る

Linux

sudo apt install git

Fedora: dnf install git

2. 初期設定（名前とメール）

        $ git config --global user.name "Your Name"

        $ git config --global user.email "you@example.com"

全てのコミットにこの名前・メールが記録される。GitHubのメールと揃えるのが推奨。

環境構築 (2/2) — GitHub接続

3. GitHubアカウント作成 & SSH鍵

        $ ssh-keygen -t ed25519 -C "you@example.com"

        # Enterを3回押す（デフォルト設定でOK）

        $ cat ~/.ssh/id_ed25519.pub

        # 出力された公開鍵をコピー

GitHub → Settings → SSH and GPG Keys → New SSH Key に貼り付ける

4. 接続確認

        $ git --version

        git version 2.44.0

        $ ssh -T git@github.com

        Hi username! You've successfully authenticated

↑ これが出ればOK！準備完了。

Gitの3つのエリア

WORKING DIR

作業ディレクトリ

ファイルを編集する場所

→
git add

STAGING

ステージング

コミットする変更を選ぶ

→
git commit

REPOSITORY

リポジトリ

履歴として永久保存

① ファイルを編集 → ② git add で選択 → ③ git commit で記録
この3ステップがGitの基本フロー

基本コマンド — 実演

Terminal — git basics

変更を確認する

git status

今どんな変更があるか確認

        On branch main

        Changes not staged:

          modified: index.html

        Untracked files:

          style.css

git diff

具体的に何が変わったか確認

@@ -1,3 +1,4 @@
 <body>
- <h1>Hello</h1>
+ <h1>Hello World</h1>
+ <p>Welcome!</p>

git status で全体把握 → git diff で詳細確認 → git add → git commit

Git と GitHub の違い

⚙️

Git

バージョン管理ツール

ローカルPC上で動く
コマンドラインツール
変更履歴を管理

≠

🐙

GitHub

Gitリポジトリのホスティング

クラウド上のサービス
コードの共有・公開
チーム協業の場

Git = 手元で履歴管理 → git push → GitHub = クラウドに保存・共有

git push → GitHubでの反映

ターミナル操作

Terminal — push to GitHub

GitHub上の変化

🐙 username / my-project main

abc1234 Initial commit

2 hours ago

📄index.htmlInitial commit

📄README.mdInitial commit

ブランチとは？

git branch feature

新しいブランチを作成

git checkout feature

ブランチに切り替え

git merge feature

mainに統合

Pull Request（PR）

PRとは？

「この変更をmainに入れてください」というリクエスト。レビューしてからマージする。

● Open Add login feature

user wants to merge 3 commits into main from feature/login

+120 lines -15 lines 3 files changed

PRの流れ

1. ブランチで作業
2. git push でGitHubに送る
3. GitHub上でPRを作成
4. チームがコードレビュー
5. 承認後マージ ✓

HANDS-ON

個人開発プロジェクトを作ろう

アイデアからGitHub公開まで、一気通貫デモ

1️⃣

リポジトリ作成

→

2️⃣

開発 & コミット

→

3️⃣

GitHub公開

→

4️⃣

機能追加

→

5️⃣

確認 & マージ

1 初期化

→

2 開発

→

3 公開

→

4 機能追加

→

5 マージ

STEP 1 — プロジェクト初期化

Terminal — Project Setup

プロジェクト構造

まだ何もない...

1 初期化

→

2 開発

→

3 公開

→

4 機能追加

→

5 マージ

STEP 2 — 開発してコミットを重ねる

Terminal — Development Cycle

コミット履歴（main）

1 初期化

→

2 開発

→

3 公開

→

4 機能追加

→

5 マージ

STEP 3 — GitHubに公開

Terminal — Publish to GitHub

🐙 username / my-todo-app

push後にここに反映される...

1 初期化

→

2 開発

→

3 公開

→

4 機能追加

→

5 マージ

STEP 4 — ブランチで新機能を開発

Terminal — Feature Branch

ブランチの様子

1 初期化

→

2 開発

→

3 公開

→

4 機能追加

→

5 マージ

STEP 5 — 変更を確認してマージ

Terminal — Review & Merge

🐙 username / my-todo-app main

マージ後にここが更新される...

📄index.html

📄style.css

📄app.js

PART 3

AIがGitを使うとき

Claude Code はなぜ・どうやってGitを使うのか

🤖 Claude Code × Git

なぜAIにGitが必要なのか？

🔒

安全性の担保

AIが書いたコードをgit diffで人間が確認してから反映できる

⏪

ロールバック

AIの変更がまずかったらgit revertで即座に元に戻せる

📝

変更の記録

AIが何をしたか、コミットメッセージとして履歴に残る

🔀

ブランチ分離

AIの作業をブランチで隔離。本番には影響しない

Claude Code のGitワークフロー

STEP 1

git status
現状を把握

→

STEP 2

git diff
変更を確認

→

STEP 3

git log
スタイル確認

→

STEP 4

git add
ファイル選択

→

STEP 5

git commit
メッセージ付き

Claudeは慎重にGitを使う: statusで確認 → diffで変更把握 → logでコミットスタイルを読む → 適切なファイルだけadd → 意味のあるメッセージでcommit

Claude がコミットする様子

Terminal — Claude Code commit process 🤖 Claude

Claude がGitで守るルール

必ずやること ✓

コミット前に git status で確認
git diff で変更内容を把握
ファイルを個別に git add
意味のあるコミットメッセージを書く
Co-Authored-By を付ける
コミット後に git status で確認

絶対しないこと ✗

git push --force 強制プッシュ
git reset --hard 変更の破棄
--no-verify フック無視
git add -A 全ファイル追加
.env や credential の commit
ユーザーの許可なく push

PR前のテスト — なぜ必要？

テストとは？

「書いたコードが正しく動くか」を自動で検証するプログラム。
人間が毎回手動で確認する代わりに、コンピュータが一瞬でチェックする。

手動テスト

ブラウザで開いて
ボタンを押して
目で確認...
遅い・漏れる

自動テスト

コマンド1つで
全機能を検証
数秒で完了
速い・確実

なぜPR前に？

壊れたコードをmainに入れない
レビュアーの負担を減らす
「動くことが保証済み」の安心感
あとで別の変更で壊れてもすぐ分かる

テストが通る = マージして大丈夫

テストの実行 — 何をしている？

Terminal — Running Tests

単体テスト (Unit)

関数1つが正しく動くか
addTodo("買い物") → OK?

結合テスト (Integration)

複数の機能が連携して動くか
追加→表示→削除の流れ

Lint / Format

コードの書き方が統一されているか
eslint, prettier

CI (自動実行)

push時にGitHub上で自動テスト
GitHub Actions

Claude がPRを作る流れ

Terminal — Creating a Pull Request 🤖 Claude

コマンドまとめ

カテゴリコマンド説明初期化git init新しいリポジトリを作成 git clone URL既存リポジトリをコピー基本git status変更状況を確認 git add ファイル変更をステージング git commit -m "msg"変更を記録確認git diff変更の差分を表示 git log --onelineコミット履歴を表示共有git pushGitHubにアップロード git pullGitHubから最新を取得分岐git branch 名前ブランチを作成 git checkout 名前ブランチを切り替え git merge 名前ブランチを統合

REAL WORLD PITFALLS

初心者がハマるポイント

本当に痛い失敗と、その乗り越え方

💥

コンフリクト

同じ行の衝突で
マージが止まる

🚫

push拒否

リモートが先に
進んでいてreject

💀

reset --hard

未保存の作業が
一瞬で消滅

🔑

秘密情報push

APIキーが全世界に
公開。botが数秒で取得

😤

間違いブランチ

数日作業した後に
mainだったと気づく

🛟

reflog

知らないと
復旧を諦めてしまう

😱 コンフリクト — 一番面倒なやつ

Terminal — Conflict Resolution

なぜ起きる？

同じファイルの同じ行を別々のブランチで編集すると発生

解決手順

1. ファイルを開く
2. <<< === >>> を探す
3. 残したい方を選ぶ
4. マーカーを消す
5. add → commit

慌てない。落ち着いて1つずつ。

🤯 pushが通らない — rejected

Terminal — Push Rejected & Fix

エラーが出たら — push rejected 編

エラーメッセージを読んで、候補を消去法で絞り込む

        ! [rejected] main -> main

        error: failed to push some refs

        hint: Updates were rejected because the remote contains work that you do not have locally.

🔍

認証エラー？ SSH鍵が通ってない？

🔍

リモートURLが間違っている？

🔍

ブランチ名が違う？

🔍

リモートが自分より先に進んでいる？

判明した原因 & 対処

リモートに自分が持っていない変更がある。先にpullで取り込む必要がある。

          $ git pull origin main

          → リモートの変更を取得・統合

          $ git push origin main

          → 成功！

エラーが出たら — コンフリクト編

merge時のエラーを読み解く思考プロセス

        CONFLICT (content): Merge conflict in index.html

        Automatic merge failed; fix conflicts and then commit the result.

🔍

ファイルが壊れた？データが消えた？

🔍

mergeコマンドの書き方を間違えた？

🔍

別のファイルを編集したのに衝突？

🔍

同じファイルの同じ行を2箇所で編集した？

判明した原因 & 対処

同じ行への変更が衝突。ファイルを開いて手動で解決する。

          $ vim index.html

          → <<< === >>> を探して修正

          $ git add index.html

          $ git commit

          → コンフリクト解消！

Git エラー対処フローチャート

エラーが出た！

↓

1. エラーメッセージを読む

英語でも最初の1行にキーワードがある

↓

2. git status で現状確認

今どのブランチ？未コミットの変更は？

↓

rejected?

git pull
してから再push

conflict?

ファイルを開いて
マーカーを修正

detached?

git checkout
でブランチに戻る

わからない?

エラー文を
そのまま検索

本当に怖いやつ

💀

git reset --hard で作業消滅

StackOverflowの「解決策」を鵜呑みにして実行。未コミットの変更が一瞬で全消去。確認ダイアログなし。Ctrl+Zなし。

        $ git reset --hard HEAD

        → 3日間の作業が消えた...

        防止策:

        $ git stash ← 危険な操作の前に退避

        $ git commit -m "WIP" ← 仮commitでもいい

        やってしまったら:

        $ git fsck --dangling ← stageした分は残ってるかも

        IDEのLocal Historyも確認

🔑

APIキーをpushした

ファイルを削除して再pushしても履歴に残っている。botが数秒でスキャンし、AWSキーなら数分で数千ドルの請求も。

        1. まずキーを無効化！

        → AWSコンソール等で即revoke

        履歴からの削除:

        $ git filter-repo --path .env --invert-paths

        → 全履歴から.envを除去

        防止策:

        .gitignore を最初に作る

        pre-commit hookで検出

やりがちなワークフロー問題

😤 間違いブランチで数日作業

mainで直接3日間コード書いてた...

📦 コミットが巨大すぎる問題

「金曜にまとめてcommit」はGitの意味がない

Bad

"updated stuff"
+2847 lines
43 files

Good

"add login form"
+45 lines
3 files

なぜダメか:

▸ コードレビューが不可能
▸ バグの原因特定ができない
▸ 1つの変更だけ戻すのが不可能
▸ git bisect が使えない

→ 1機能 = 1コミットが目安

🛟 git reflog — 「全部消えた」は嘘

Gitは過去90日間のHEADの移動を全て記録している。ほぼ何でも復旧できる。

Terminal — git reflog: Your Safety Net

.gitignore — なぜ必要？

設定ファイル例

        # 環境変数（秘密情報）

        .env

        .env.local

        # 依存パッケージ

        node_modules/

        venv/

        # ビルド出力

        dist/

        build/

        # OS生成ファイル

        .DS_Store

        Thumbs.db

ignoreしないと何が起きる？

▸ APIキーが全世界に公開される
▸ node_modules（数万ファイル）をpush
▸ cloneに30分かかるリポジトリ完成
▸ 他人のPCで動かないゴミが混入

プロジェクト開始時に最初に作るファイル！

git init → .gitignore → 最初のcommit

.gitignore — 各ディレクトリ・ファイルの正体

名前何が入っている？サイズなぜignore？ .env APIキー、DB接続先、パスワードなどの秘密情報数KB 漏洩したら事故。絶対NG node_modules/ npm install でDLされるライブラリ全部数百MB npm install で再生成できる venv/ Python仮想環境。pipでDLしたライブラリ全部数百MB pip install -r requirements.txt で再生成 dist/ distributionの略。ビルド後の配布用ファイル（JS圧縮版等）数MB npm run build で再生成できる build/ コンパイル・ビルドの出力先。distと同じ役割数MB ソースから何度でも作れる .DS_Store macOS Finderが自動生成。フォルダの表示設定を保存数KB mac固有。他のOSには無意味 Thumbs.db Windowsが自動生成。画像サムネイルのキャッシュ数KB Windows固有。他のOSには無意味 __pycache__/ Pythonが自動生成するコンパイル済みファイル (.pyc) 数MB 実行すれば自動で作られる .idea/ JetBrains IDEの設定。.vscode/ はVS Codeの設定数KB 個人のエディタ設定。共有不要 *.log アプリが出力するログファイル。デバッグ情報等数MB〜実行ごとに変わる一時データ

共通ルール: 再生成できるもの・秘密情報・個人環境固有のもの は全てignore

まとめ

📦

Git = 履歴管理

変更を記録して
いつでも戻れる

🌐

GitHub = 共有

コードをクラウドに
チームで協業

🤖

AI × Git = 安全

AIの変更も履歴に
レビュー可能

まずは git init から始めよう！

失敗しても大丈夫。Gitがあれば戻れるから。

Appendix: コマンドリファレンス

コマンド	説明
`git config --global`	Gitのユーザー名・メールアドレスを設定
`ssh-keygen`	SSH鍵を生成（GitHub認証用）
`git init`	新しいリポジトリを初期化
`git clone URL`	既存のリポジトリをコピーして取得
`git status`	作業ディレクトリの変更状況を確認
`git diff`	変更内容の差分を表示
`git add`	変更をステージングエリアに追加
`git commit -m "msg"`	ステージングした変更を履歴に記録
`git log`	コミット履歴を表示
`git remote add origin URL`	リモートリポジトリを紐付け
`git push`	ローカルの変更をGitHubにアップロード
`git pull`	GitHubから最新の変更を取得・統合
`git branch`	ブランチを作成・一覧表示
`git checkout`	ブランチを切り替え
`git merge`	別のブランチの変更を現在のブランチに統合
`git reset --hard`	指定したコミットまで強制的に巻き戻し（変更は消える）
`git reflog`	HEADの移動履歴を表示（resetで消えたコミットも復元可能）
`git revert`	指定したコミットを打ち消す新しいコミットを作成

Git & GitHub 入門

この編の全体像

Gitの基礎知識

基本操作を覚える

個人開発の流れ

AIとGit

トラブルシューティング

設定と管理

Gitとは？

なぜGitが必要なのか？

履歴管理

チーム開発

ブランチ

バックアップ

Gitの用語を知ろう

リポジトリ（Repository）

ローカル / リモート

クローン（Clone）

コミット（Commit）

プッシュ（Push）

プル（Pull）

ローカルとリモートの関係

ローカルリポジトリ

リモートリポジトリ

環境構築 (1/2) — インストール

1. Gitのインストール

2. 初期設定（名前とメール）

環境構築 (2/2) — GitHub接続

3. GitHubアカウント作成 & SSH鍵

4. 接続確認

Gitの3つのエリア

基本コマンド — 実演

変更を確認する

Git と GitHub の違い

Git

GitHub

git push → GitHubでの反映

ブランチとは？

Pull Request（PR）

個人開発プロジェクトを作ろう

STEP 1 — プロジェクト初期化

STEP 2 — 開発してコミットを重ねる

STEP 3 — GitHubに公開

STEP 4 — ブランチで新機能を開発

STEP 5 — 変更を確認してマージ

AIがGitを使うとき

なぜAIにGitが必要なのか？

安全性の担保

ロールバック

変更の記録

ブランチ分離

Claude Code のGitワークフロー

Claude がコミットする様子

Claude がGitで守るルール

PR前のテスト — なぜ必要？

テストの実行 — 何をしている？

Claude がPRを作る流れ

コマンドまとめ

初心者がハマるポイント

😱 コンフリクト — 一番面倒なやつ

🤯 pushが通らない — rejected

エラーが出たら — push rejected 編

エラーが出たら — コンフリクト 編

Git エラー対処フローチャート

本当に怖いやつ

やりがちなワークフロー問題

🛟 git reflog — 「全部消えた」は嘘

.gitignore — なぜ必要？

.gitignore — 各ディレクトリ・ファイルの正体

まとめ

Git = 履歴管理

GitHub = 共有

AI × Git = 安全

Appendix: コマンドリファレンス

エラーが出たら — コンフリクト編