読み込み中...
バイブコーディング時代のGit/GitHub入門
バイブコーディング時代のGit/GitHub入門
はじめに
最近話題のバイブコーディング。CursorやClaude Code、GitHub CopilotなどのAIツールに指示を出して、コードを書いてもらうスタイルの開発手法です。
AIがコードを書いてくれるなら、ファイル管理なんて適当でいい？
...と思いたいところですが、実はここが最大の落とし穴です。
バイブコーディングでは、AIが一度に大量のコードを変更します。そのとき、こんなことが起きます：
こんな経験、ありませんか？
これらの問題は、Gitを使うだけで解決します。Gitがあれば、コードの変更履歴をすべて記録し、いつでも好きな時点に戻すことができます。
この記事を読めば、Gitの基本をマスターし、AIと安心して開発できる環境を手に入れることができます。
なぜバイブコーディングにGitが必要なのか
従来のプログラミングでは、自分が書いたコードだから、何をどう変えたか把握できていました。
しかしバイブコーディングでは状況が違います：
1. AIは大量のコードを一気に変更する
「ログイン機能を追加して」と頼むだけで、AIは5つも10つもファイルを同時に変更します。すべての変更を自分の目で追うのは現実的ではありません。
2. AIは「元に戻す」のが苦手
AIに「さっきの変更を元に戻して」と頼んでも、完璧には戻してくれないことが多いです。記憶が曖昧だったり、別の部分まで変えてしまったりします。
3. 試行錯誤が前提の開発スタイル
バイブコーディングでは「とりあえずAIに試してもらって、ダメなら戻す」という進め方が基本です。安心して「戻せる」環境がないと、怖くて新しいことを試せません。
Gitはまさに、この「安心して試行錯誤できる環境」を作ってくれるツールです。
Gitってなに？
一言でいうと
ファイルの変更履歴を記録・管理するためのツールです。正式には「バージョン管理システム」と呼ばれます。
もう少し詳しく
Gitを使うと、プロジェクトのファイルに対する変更をスナップショットとして保存できます。このスナップショットのことを「コミット」と呼びます。
イメージとしては、ゲームのセーブポイントに似ています：
1セーブ1：プロジェクト作成直後
2セーブ2：ヘッダーのデザインを追加
3セーブ3：ログイン機能を追加
4セーブ4：AIにデザインを修正してもらった ← 今ここもし「セーブ4」の状態がおかしくなったら、「セーブ3」に戻せます。ファイルを手動でコピーしたり、「元に戻す」を連打したりする必要はありません。
Gitの記録は「差分」で管理される
Gitは毎回ファイル全体をコピーしているわけではありません。前回からの差分（変わった部分だけ） を記録しています。だから、何百回コミットしても容量はそこまで大きくなりません。
GitHubってなに？
GitとGitHubは別のものです。混同しやすいので、ここで整理しておきます。
| Git | GitHub | |
|---|---|---|
| 何か | バージョン管理ツール | Gitのデータを保存するWebサービス |
| どこで動く | 自分のパソコン（ローカル） | インターネット上（クラウド） |
| 必須か | はい | いいえ（でも使うべき） |
Gitは自分のパソコンの中で動くツールです。ファイルの変更履歴を記録します。
GitHubは、Gitで記録した履歴をインターネット上に保存できるサービスです。
GitHubを使うメリット：
バイブコーディングでも、「GitHubにコードを上げておく」習慣をつけると、万が一のときに安心です。
Gitのインストール
Macの場合
Macには、Xcode Command Line Toolsをインストールすると、Gitも一緒に入ります。
ターミナルを開いて、以下を実行してください：
1xcode-select --installダイアログが表示されたら「インストール」をクリックして、完了を待ちます。
インストールが終わったら、確認：
1git --versiongit version 2.x.x のように表示されればOKです。
Windowsの場合
Git for Windowsをインストールします。
1. https://gitforwindows.org/ にアクセス
2. 「Download」ボタンをクリック
3. ダウンロードしたインストーラーを実行
4. 基本的にすべてデフォルト設定のまま「Next」で進めてOK
インストールが終わったら、コマンドプロンプト（またはGit Bash）を開いて確認：
1git --versionバージョンが表示されれば成功です。
Gitの初期設定
Gitを使い始める前に、名前とメールアドレスを設定します。これは、「誰がこの変更をしたか」を記録するためのものです。
1git config --global user.name "あなたの名前"
2git config --global user.email "your-email@example.com"たとえば：
1git config --global user.name "Tanaka Taro"
2git config --global user.email "tanaka@example.com"--global をつけると、パソコン全体で有効になります。一度設定すれば、以降は不要です。
設定内容を確認するには：
1git config --listuser.name と user.email が表示されていればOKです。
Gitの基本操作
ここからが本番です。実際にGitを使ってみましょう。
ステップ1：プロジェクトフォルダを作る
まず、練習用のプロジェクトフォルダを作ります。
1mkdir git-practice
2cd git-practiceステップ2：Gitリポジトリを作成する（git init）
このフォルダをGitで管理するために、リポジトリ（repository） を作成します。
1git init実行すると、以下のようなメッセージが表示されます：
1Initialized empty Git repository in /Users/yourname/git-practice/.git/これで、git-practice フォルダの中に .git という隠しフォルダが作成されました。この .git フォルダの中に、すべての変更履歴が保存されていきます。
注意： .git フォルダは絶対に手動で削除・編集しないでください。変更履歴がすべて消えてしまいます。
ステップ3：ファイルを作成する
練習用にファイルを作りましょう。テキストエディタで index.html を作成してください：
1<!DOCTYPE html>
2<html lang="ja">
3<head>
4 <meta charset="UTF-8">
5 <title>Git練習</title>
6</head>
7<body>
8 <h1>はじめてのGit</h1>
9 <p>Gitの練習中です。</p>
10</body>
11</html>ステップ4：変更状態を確認する（git status）
ファイルを作ったら、Gitがどう認識しているか確認してみましょう。
1git status出力：
1On branch main
2
3No commits yet
4
5Untracked files:
6 (use "git add <file>..." to include in what will be committed)
7 index.html
8
9nothing added to commit but untracked files present (use "git add" to track)Untracked files と表示されています。これは「Gitがまだ追跡していないファイルがある」という意味です。Gitにファイルを認識させるには、次のステップで「ステージング」する必要があります。
ステップ5：ファイルをステージングする（git add）
Gitでは、コミット（保存）する前に、どのファイルをコミットに含めるかを選ぶ必要があります。この作業を「ステージング」と呼びます。
1git add index.html複数ファイルをまとめてステージングしたい場合：
1git add ..（ドット）は「現在のフォルダにあるすべての変更ファイル」を意味します。
ステージング後にもう一度 git status で確認してみましょう：
1git status出力：
1On branch main
2
3No commits yet
4
5Changes to be committed:
6 (use "git rm --cached <file>..." to unstage)
7 new file: index.htmlChanges to be committed に変わりました。これで、コミットする準備ができています。
ステップ6：コミットする（git commit）
いよいよ、変更を記録（コミット）します。
1git commit -m "最初のコミット：index.htmlを追加"-m の後ろに、コミットメッセージを書きます。これは「何を変更したか」のメモです。将来の自分が見て分かるように、具体的に書きましょう。
出力：
1[main (root-commit) abc1234] 最初のコミット：index.htmlを追加
2 1 file changed, 11 insertions(+)
3 create mode 100644 index.htmlこれで、最初のセーブポイントが作成されました。
git add と git commit の関係を整理
この2段階のプロセスは、初心者にとって少し分かりにくいポイントです。図で整理しましょう。
1【作業ディレクトリ】 ---git add---> 【ステージングエリア】 ---git commit---> 【リポジトリ（履歴）】
2 ファイルを編集 コミットに含める 変更を記録
3 ファイルを選ぶ （セーブ）なぜ2段階なのか？それは、変更の一部だけをコミットしたい場合があるからです。
たとえば、5つのファイルを変更したけど、まずヘッダーの変更だけをコミットしたい、という場面です。git add で必要なファイルだけを選んで、git commit で記録する、という流れです。
変更を記録してみよう（実践）
最初のコミットができたので、次はファイルを変更してコミットする練習をしましょう。
ファイルを編集する
index.html を開いて、内容を変更します：
1<!DOCTYPE html>
2<html lang="ja">
3<head>
4 <meta charset="UTF-8">
5 <title>Git練習</title>
6</head>
7<body>
8 <h1>はじめてのGit</h1>
9 <p>Gitの練習中です。</p>
10 <p>変更を記録する練習をしています。</p>
11</body>
12</html>1行追加しました。
差分を確認する（git diff）
コミットする前に、何が変わったのかを確認しましょう。
1git diff出力：
1diff --git a/index.html b/index.html
2index abc1234..def5678 100644
3--- a/index.html
4+++ b/index.html
5@@ -8,5 +8,6 @@
6 <body>
7 <h1>はじめてのGit</h1>
8 <p>Gitの練習中です。</p>
9+ <p>変更を記録する練習をしています。</p>
10 </body>
11 </html>+ がついている行が追加された行です。- がついていれば削除された行になります。
バイブコーディングでは、この git diff が特に重要です。AIがどこを変更したのかを、自分の目で確認できます。
ステージングしてコミット
1git add .
2git commit -m "本文に1行追加"履歴を確認する（git log）
これまでのコミット履歴を見てみましょう。
1git log出力：
1commit def5678... (HEAD -> main)
2Author: Tanaka Taro <tanaka@example.com>
3Date: Sat Feb 22 10:30:00 2026 +0900
4
5 本文に1行追加
6
7commit abc1234...
8Author: Tanaka Taro <tanaka@example.com>
9Date: Sat Feb 22 10:15:00 2026 +0900
10
11 最初のコミット：index.htmlを追加2つのコミットが記録されています。最新のコミットが上に表示されます。
履歴をシンプルに表示したい場合は：
1git log --oneline出力：
1def5678 本文に1行追加
2abc1234 最初のコミット：index.htmlを追加1行ずつコンパクトに表示されて見やすいです。
.gitignore -- 追跡しないファイルを指定する
プロジェクトには、Gitで管理すべきでないファイルもあります：
これらをGitに含めないように、.gitignore ファイルを作ります。
.gitignoreを作成する
プロジェクトのルートに .gitignore という名前のファイルを作成し、以下のように記述します：
1# 秘密情報
2.env
3
4# Python
5venv/
6__pycache__/
7*.pyc
8
9# Node.js
10node_modules/
11
12# OS生成ファイル
13.DS_Store
14Thumbs.db# で始まる行はコメントです。
.gitignoreもコミットする
.gitignore ファイル自体はGitで管理します。チームメンバーや、別のPCで作業するときにも設定が共有されるようにするためです。
1git add .gitignore
2git commit -m ".gitignoreを追加"バイブコーディングでの注意点
AIに「.envファイルにAPIキーを保存して」と言われることがあります。そのとき、絶対に `.env` をGitにコミットしないでください。 APIキーがGitHubで公開されると、不正利用される危険があります。
.gitignore に .env が含まれていることを必ず確認しましょう。
GitHubを使ってみよう
ここからは、ローカル（自分のパソコン）のGitリポジトリを、GitHubにアップロードする方法を学びます。
GitHubアカウントを作成する
まだアカウントを持っていない方は、以下の手順で作成してください。
1. https://github.com/ にアクセス
2. 「Sign up」をクリック
3. メールアドレス、パスワード、ユーザー名を入力
4. メール認証を完了
ユーザー名は、今後GitHubのURLに使われます（github.com/ユーザー名）。後から変更もできますが、なるべく覚えやすいものにしましょう。
GitHubにリポジトリを作成する
1. GitHubにログインして、右上の「+」ボタンから「New repository」をクリック
2. 以下を入力：
- Repository name ：git-practice（プロジェクト名と同じにすると分かりやすい）
- Description ：任意で説明を入力
- Public / Private ：練習なので「Public」でもOK（公開したくなければ「Private」）
3. 「Create repository」をクリック
作成すると、セットアップ用のコマンドが表示されます。
ローカルのリポジトリをGitHubに接続する（git remote add）
GitHubに作成したリポジトリと、自分のパソコンのリポジトリを接続します。
1git remote add origin https://github.com/ユーザー名/git-practice.gitorigin は、リモート（GitHub）リポジトリにつける名前です。慣例的に origin を使いますコードをGitHubにアップロードする（git push）
1git push -u origin mainpush ：ローカルの変更をリモート（GitHub）に送る-u origin main ：「今後 git push だけで origin の main ブランチに送る」という設定初回のプッシュ時に、GitHubのユーザー名とパスワード（またはトークン）の入力を求められることがあります。
パスワードの代わりにPersonal Access Tokenが必要な場合：
GitHubはパスワード認証を廃止しています。代わりに「Personal Access Token（PAT）」を使います。
1. GitHubで、右上のアイコン →「Settings」→「Developer settings」→「Personal access tokens」→「Tokens (classic)」
2. 「Generate new token」をクリック
3. 必要な権限（repo にチェック）を選んでトークンを生成
4. 表示されたトークンをパスワードの代わりに入力
2回目以降の git push では：
1git pushこれだけでOKです（-u で設定済みなので）。
GitHubでコードを確認する
プッシュが成功したら、ブラウザで https://github.com/ユーザー名/git-practice にアクセスしてみてください。自分のコードがGitHubに表示されているはずです。
README.mdを追加する
GitHubのリポジトリページでは、README.md ファイルの内容が自動的に表示されます。プロジェクトの説明を書いておきましょう。
プロジェクトフォルダに README.md を作成：
1# Git練習プロジェクト
2
3Gitの基本操作を練習するためのプロジェクトです。
4
5## 使い方
6
71. このリポジトリをクローンする
82. ブラウザで `index.html` を開くコミットしてプッシュ：
1git add README.md
2git commit -m "README.mdを追加"
3git pushGitHubのリポジトリページをリロードすると、READMEの内容が表示されるようになります。
実践シナリオ：AIが書いたコードを壊してしまった！git checkoutで戻す
ここからは、バイブコーディングで実際に起きがちな場面をシミュレーションしてみましょう。
シナリオ
あなたはAIに「ヘッダーのデザインをかっこよくして」と頼みました。AIは index.html を大幅に変更しました。ところが、変更後のページを確認すると...レイアウトが完全に崩れています。
「元に戻したい！」
まず、コミットしてある状態を確認する
前提として、AIに変更を頼む前にコミットしてあることが重要です。これがバイブコーディングでGitを使う最大のポイントです。
1セーブ3：ヘッダーのデザインが正常に動いている状態 ← ここにコミット済み
2 ↓
3AIに「かっこよくして」と依頼
4 ↓
5現在：レイアウトが崩壊 ← まだコミットしていない変更内容を確認する（git diff）
まず、AIが何を変えたのかを確認しましょう。
1git diff大量の差分が表示されます。ここで「これは元に戻したほうがいい」と判断したとします。
変更を取り消す（git checkout）
コミットしていない変更を取り消して、直前のコミットの状態に戻すには：
1git checkout -- index.htmlこれで、index.html が最後にコミットした時点の状態に戻ります。
全ファイルをまとめて戻す場合：
1git checkout -- .変更を取り消す（git restore）-- 新しい方法
Git 2.23以降では、git restore コマンドも使えます。checkout より意味が分かりやすいので、こちらもおすすめです。
1git restore index.html全ファイルを戻す場合：
1git restore .バイブコーディングでの鉄則
この経験から学べる、バイブコーディングの鉄則があります：
AIに大きな変更を頼む前に、必ずコミットする。
具体的なワークフロー：
1# 1. 現在の状態をコミット（セーブポイント作成）
2git add .
3git commit -m "AIに修正を頼む前の状態"
4
5# 2. AIに変更を依頼する
6# （AIがファイルを変更する）
7
8# 3. 結果を確認
9git diff
10
11# 4-A. うまくいった場合 → コミット
12git add .
13git commit -m "AIにヘッダーのデザインを改善してもらった"
14
15# 4-B. うまくいかなかった場合 → 元に戻す
16git restore .このサイクルを繰り返すだけで、安心してAIに色々な変更を試してもらえます。
もう少し進んだ復元テクニック
特定のコミットに戻したい場合
「2つ前のセーブポイントに戻したい」というケースもあります。
まず、コミット履歴を確認：
1git log --oneline出力：
1def5678 AIにヘッダーを修正してもらった
2abc1234 本文に1行追加
3xyz9876 最初のコミット：index.htmlを追加特定のコミットの状態をファイルに反映するには：
1git checkout abc1234 -- index.htmlabc1234 はコミットIDです（git log --oneline で確認した英数字の部分）。
これで index.html が abc1234 のコミット時点の内容に戻ります。戻した変更をコミットして確定しましょう：
1git add index.html
2git commit -m "index.htmlをabc1234の状態に戻した"ステージングを取り消す（git addの取り消し）
git add でステージングしたけど、やっぱりやめたい場合：
1git restore --staged index.html全ファイルのステージングを取り消す：
1git restore --staged .これはあくまでステージングの取り消しで、ファイルの内容は変わりません。
ブランチの基本
ここまでの操作は、すべて main ブランチ（メインの作業場所）で行ってきました。ここでは、ブランチの基本概念だけ紹介します。
ブランチとは
ブランチは、メインの作業場所とは別の、独立した作業スペースを作る機能です。
1main : ●---●---●---● ← 安定した本線
2 \
3feature: ●---● ← 新機能を試す別線メインのコードに影響を与えずに、新しい機能を試したり、実験したりできます。
基本的なブランチ操作
新しいブランチを作成して移動する：
1git checkout -b feature/new-headerこれで feature/new-header という名前の新しいブランチが作成され、そこに移動します。
今いるブランチを確認する：
1git branch出力（* がついているのが現在のブランチ）：
1 main
2* feature/new-headerこのブランチで作業してコミット：
1# ファイルを編集...
2git add .
3git commit -m "新しいヘッダーデザインを試作"ブランチを切り替える
mainブランチに戻る：
1git checkout mainバイブコーディングでのブランチ活用
AIに大きな変更を頼むとき、ブランチを使うとさらに安全です：
1# 1. 新しいブランチを作成
2git checkout -b feature/ai-redesign
3
4# 2. AIに大きな変更を依頼
5# （AIがファイルを大幅に変更する）
6
7# 3. うまくいったらmainに反映
8git checkout main
9git merge feature/ai-redesign
10
11# 3. うまくいかなかったらブランチごと捨てる
12git checkout main
13git branch -d feature/ai-redesignブランチについてはここでは基本だけに留めますが、慣れてきたらぜひ活用してみてください。
よくあるミスと解決方法
1. コミットメッセージを間違えた
対処法： 直前のコミットメッセージを修正できます。
1git commit --amend -m "正しいコミットメッセージ"注意： すでに git push したコミットは、修正すると問題が起きることがあります。プッシュ前の修正に限りましょう。
2. コミットし忘れてたファイルがあった
対処法： ファイルを追加して、直前のコミットに含める。
1git add 忘れていたファイル名
2git commit --amend --no-edit--no-edit は「コミットメッセージはそのまま」という意味です。
3. git add . で余計なファイルまでステージングしてしまった
対処法： ステージングを個別に取り消す。
1git restore --staged 余計なファイル名4. 「fatal: not a git repository」と表示される
原因： git init を実行していないフォルダでGitコマンドを使おうとしている。
対処法： 正しいフォルダにいるか確認して、必要なら git init を実行。
1pwd # 今いるフォルダを確認
2git init # 必要に応じて実行5. 「error: failed to push some refs to...」と表示される
原因： GitHub上にローカルにはない変更がある（他のPCや、GitHubのWebサイトで直接編集した場合など）。
対処法： まずリモートの変更を取り込んでからプッシュ。
1git pull origin main
2git push6. 大きなファイルをコミットしてしまった
対処法： 今後は .gitignore に追加する。すでにコミットしたファイルの追跡を止めるには：
1git rm --cached 大きなファイル名
2echo "大きなファイル名" >> .gitignore
3git add .
4git commit -m "大きなファイルの追跡を解除"Gitコマンド チートシート
最後に、この記事で学んだコマンドを一覧にまとめます。
初期設定
| やりたいこと | コマンド |
|---|---|
| 名前を設定 | git config --global user.name "名前" |
| メールを設定 | git config --global user.email "メール" |
| 設定を確認 | git config --list |
基本操作
| やりたいこと | コマンド |
|---|---|
| リポジトリを作成 | git init |
| 状態を確認 | git status |
| 差分を確認 | git diff |
| ファイルをステージング | git add ファイル名 |
| 全ファイルをステージング | git add . |
| コミット | git commit -m "メッセージ" |
| 履歴を確認 | git log |
| 履歴を1行で確認 | git log --oneline |
変更の取り消し
| やりたいこと | コマンド |
|---|---|
| ファイルの変更を取り消す | git restore ファイル名 |
| 全ファイルの変更を取り消す | git restore . |
| ステージングを取り消す | git restore --staged ファイル名 |
| 特定のコミットに戻す | git checkout コミットID -- ファイル名 |
GitHub連携
| やりたいこと | コマンド |
|---|---|
| リモートを追加 | git remote add origin URL |
| 初回プッシュ | git push -u origin main |
| 2回目以降のプッシュ | git push |
| リモートの変更を取り込む | git pull origin main |
ブランチ
| やりたいこと | コマンド |
|---|---|
| ブランチを作成して移動 | git checkout -b ブランチ名 |
| ブランチを切り替え | git checkout ブランチ名 |
| ブランチ一覧を確認 | git branch |
| ブランチをマージ | git merge ブランチ名 |
| ブランチを削除 | git branch -d ブランチ名 |
まとめ
この記事で学んだことを振り返りましょう。
Gitの基本概念：
基本ワークフロー：
git init でリポジトリを作成git add でステージング、git commit で記録git status と git diff でこまめに状態を確認git push でGitHubにアップロードバイブコーディングでの鉄則：
git commit するgit diff で確認するgit restore . で元に戻すこの3つを守るだけで、バイブコーディングの安心感が大きく変わります。
Gitは奥が深いツールですが、この記事で紹介した基本操作だけでも、日常の開発には十分です。まずは今日から git init して、コミットする習慣をつけてみてください。
さあ、Gitの準備ができたら、AIと一緒にコードを書いてみましょう！
おすすめのコース
AIでWebアプリを開発して公開するまでの全体像
AIを使ってWebアプリを作り、実際にインターネットに公開するまでの全体像をわかりやすく解説します。企画→開発→デプロイの流れ、使うツールや技術の選び方、初心者が陥りやすい落とし穴まで、バイブコーディング時代の開発プロセスを俯瞰できるコラムです。
無料
Claude Codeってなに？導入から使い方まで完全ガイド
AIがコードを書いてくれる「Claude Code」を徹底解説。Claude Codeとは何か、何ができるのか、インストール方法から基本的な使い方まで、初心者にもわかりやすくステップバイステップで紹介します。バイブコーディングを始めたい方の最初の一歩に最適な無料講座です。
無料
もう怖くない！エラーメッセージの読み方入門
プログラミング初心者が最もつまずく「エラーメッセージ」を徹底攻略します。赤い文字や英語の羅列に怯える必要はもうありません。この無料講座では、Pythonのエラーメッセージの読み方を「下から上へ」のシンプルなルールで解説し、よく出る10大エラーの原因と対処法を具体的なコード例とともに紹介します。エラーを「敵」から「味方」に変えて、バイブコーディングをもっとスムーズに進めましょう。
無料
APIキーを安全に管理しよう！.envファイル入門
AIサービスやWeb APIを使う開発で避けて通れない「APIキーの管理」を基礎から解説します。キーをソースコードに直書きしてGitHubに公開してしまい、高額請求が届く――そんな事故を防ぐために、.envファイルとpython-dotenvを使った安全な管理方法を、初心者にもわかりやすく実践的に学びます。
無料