このページのゴールと全体像
この解説では、バラバラに覚えがちな Git / GitHub の基本コマンドを「一本のストーリーライン」でつなぎます。 ローカルでの開発開始から GitHub への公開、新機能開発、緊急対応（hotfix）までを通して、コマンドと履歴構造の関係を整理します。
このストーリーで登場する主なコマンド
プロジェクトを通して、次のようなコマンドが登場します。
- リポジトリ開始
git init,git status,git add,git commit,git log,git diff - GitHub 連携
git remote add,git remote -v,git push - ブランチ操作
git branch,git switch - 更新反映
git fetch,git merge,git pull
プロジェクトの始まり：ローカルで Git 管理を始める
あなたは新しい Web アプリ awesome-app を作り、まずはローカルで Git 管理をスタートします。 ここでは、リポジトリの初期化から、最初のコミットまでの流れを見ていきます。
Step 1：リポジトリの初期化と初回コミット
まずディレクトリを作成し、Git 管理を開始して最初のコミットを作ります。
- プロジェクトディレクトリの作成と移動
mkdir awesome-app
cd awesome-app- Git 管理を開始：
git init
git init- 状態：
awesome-app/.gitが作られ、空の Git リポジトリになる（まだコミットはない）
- ファイルを作成（例：
index.htmlとapp.js）
echo "<!doctype html>" > index.html
echo "console.log('Hello');" > app.js- 状態確認：
git status
git status- 状態：
index.htmlとapp.jsが「Untracked files」として表示される
- ステージング：
git add
git add .- 状態：2つのファイルが「次のコミットに含める対象」としてステージに乗る
- 初回コミット：
git commit
git commit -m "Initial commit: basic HTML and JS"- 状態：main ブランチに最初のコミット C0 ができる
- コミット履歴の確認：
git log
git log --oneline- 状態：
C0 Initial commit: ...のような履歴が 1 件表示される
Step 1 終了時の履歴状態（gitGraph）
初回コミット C0 が main に作られた状態を、Mermaid の gitGraph で表現すると次のようになります。
GitHub とつなぐ：リモート設定と初回 push
ローカルで始めたプロジェクトを、GitHub に公開します。ここではリモートの設定と初回 push を行います。
Step 2：リモート追加と main の公開
GitHub 側で空のリポジトリを作成したあと、ローカルリポジトリから接続します。
- GitHub で
awesome-appリポジトリを作成
- 例：
https://github.com/tee/awesome-app.gitが用意される
- リモートを登録：
git remote add origin
git remote add origin https://github.com/tee/awesome-app.git- リモート一覧の確認：
git remote -v
git remote -v- 状態：
origin https://github.com/tee/awesome-app.git (fetch/push)が表示される
- main ブランチを GitHub へ初回 push：
git push
git push -u origin main- 状態：GitHub 側の
mainに C0 が反映される - 状態：ローカル
mainはorigin/mainと追跡関係になる
Step 2 終了時の履歴状態（gitGraph）
リモート設定と push はコミットグラフそのものは変えません。したがって履歴は Step 1 のままです。
新機能開発：feature ブランチでログイン画面を作る
ここからは、ログイン機能を追加するために feature ブランチを切って作業します。 ブランチ操作と差分確認のコマンドが登場します。
Step 3：feature ブランチでの開発と push
main から feature/login-form を作り、ログイン画面の UI とバリデーションを実装していきます。
- ブランチ作成：
git branch
git branch feature/login-form- 状態：履歴は C0 のままだが、
feature/login-formという分岐候補ができる
- ブランチ切り替え：
git switch
git switch feature/login-form- 状態：作業ブランチが
feature/login-formになる（中身は C0 と同じ状態でスタート）
- ログインフォームの追加（ファイル編集）
# 例：index.html にログインフォームを追記- 状態確認：
git status
git status- 差分確認：
git diff
git diff- 状態：ログインフォームの追加内容が差分として表示される
- ステージング：
git add
git add index.html- コミット：
git commit
git commit -m "Add basic login form"- 状態：
feature/login-form上に C1 ができる（C0 → C1）
- GitHub に feature ブランチを push：
git push
git push -u origin feature/login-form- 状態：GitHub に
feature/login-formブランチが作成され、C1 が共有される
Step 3.5：バリデーション改善コミットを追加
バリデーション強化などを行い、追加コミット C2 を積みます。
# コード編集（バリデーション強化など）
git diff
git add .
git commit -m "Improve login form validation"
git push- 状態：
feature/login-formはC0 - C1 - C2という履歴になる
Step 3 終了時の履歴状態（gitGraph）
main から分岐した feature ブランチが C2 まで進んだ状態を図にすると、次のようになります。
GitHub の更新をローカルに取り込む：fetch / merge / pull
GitHub 上で Pull Request をマージしたあと、ローカルの main に変更を反映します。
ここでは git fetch, git merge, git pull の関係を確認します。
Step 4：feature を main に取り込み、ローカルを最新にする
GitHub で PR をマージしたあと、ローカルの main を更新します。
- GitHub 上で PR 作成・マージ
- 状態：GitHub の
mainブランチがC0 - C1 - C2になる
- ローカルで main に切り替え：
git switch
git switch main- リモートの情報取得：
git fetch
git fetch origin- 状態：ローカルの
origin/mainがC0 - C1 - C2を指す
- リモート main をローカル main に反映：
git merge
git merge origin/main- 状態：ローカル
mainもC0 - C1 - C2になる（fast-forward マージ）
- まとめて行う場合：
git pull
git pull origin main- 状態：
git fetch+git mergeを一度に実行したのと同じ結果
Step 4 終了時の履歴状態（gitGraph）
feature ブランチの内容が main に取り込まれた状態を図にすると、次のようになります。
緊急対応：hotfix ブランチでセキュリティ修正
公開後にセキュリティ問題が見つかり、hotfix ブランチで修正するケースを通して、 ブランチ作成とマージをもう一度確認します。
Step 5：hotfix ブランチで修正して main へマージ
最新の main から hotfix/security-patch を作り、セキュリティ修正を適用します。
- 最新 main に切り替えと更新
git switch main
git pull origin main- hotfix ブランチ作成：
git branch
git branch hotfix/security-patch- hotfix ブランチへ切り替え：
git switch
git switch hotfix/security-patch- セキュリティ修正の実装（ファイル編集）
# 例：app.js でパスワードの扱いを修正- 差分確認とステージング・コミット
git diff
git add app.js
git commit -m "Apply security patch for login"Step 5（コミット完了時点）の履歴状態（gitGraph）
hotfix ブランチで C3 が作られた直後の状態を図にすると、次のようになります。
- GitHub に hotfix ブランチを push：
git push
git push -u origin hotfix/security-patch- GitHub で PR 作成・マージ → main 更新
- 状態：GitHub の
mainはC0 - C1 - C2 - C3という履歴になる
- ローカル main に反映：
git switchとgit pull
git switch main
git pull origin main- 状態：ローカル main も
C0 - C1 - C2 - C3となり、hotfix が反映される
最終的な履歴構造：Mermaid gitGraph で可視化
ここまでの物語で作られたコミットとブランチの関係を、Mermaid の gitGraph で図示します。
各 Step の gitGraph をまとめた最終形が次の図です。
最終的なコミット構造
最終的なコミット構造は次のようになっています。
- main：
C0（初回） →C1（ログイン UI） →C2（バリデーション強化） →C3（セキュリティ hotfix） - feature/login-form：
C0から分岐しC1→C2を積み、その後 main にマージされる - hotfix/security-patch：main の
C2から分岐しC3を作り、main にマージされる
この図と、各ステップで使ったコマンドを対応づけて眺めることで、 「どのコマンドがどの線・どの点を生み出しているか」 が直感的に整理できます。
次の一歩：この物語を自分の環境で再現する
あとは、このページで紹介したコマンドをそのままローカルのダミープロジェクトで実行してみると、 Git / GitHub の基本的な流れがかなり身体感覚として入ってきます。
- 任意のフォルダで
awesome-appのようなディレクトリを作る - このページのコマンドを上から順に実行していく
- 途中で
git log --oneline --graph --allを打って、Mermaid の図と見比べる
必要であれば、VSCode 前提の画面キャプチャ付きバージョンや、 コマンド数をもっと絞った「最小セット版」の HTML も作成できます。