1.1 pushまでの一連の流れ

この章では、Git を使った日常的な開発作業の 基本フロー を学んでいきます。
まずはここをしっかり理解しておくと、後の応用がぐっとスムーズになりますよ 🚀

この章のゴール

1. develop ブランチから作業用ブランチを作成できる
2. git status / git log / git diff で現在の状態を正しく把握できる
3. add → commit → push の一連の流れを理解し、実行できる
4. 各コマンドが 「何をしているか」 をイメージできる

---

準備

まずは、作業を行うディレクトリを作りましょう。
作ったら、 そのディレクトリの中で、git init と打ってみてください。
これで準備は完了です。

Gitの全体像をつかもう

コマンドを覚える前に、Git がどのようにファイルの履歴を管理しているかを把握しておきましょう。
Git には 「4つの場所」 があり、これから説明するコマンドは この場所の間でデータを移動させる操作 です。

flowchart LR
    A["🖥️ 作業ディレクトリ
(Working Directory)"]
    B["📋 ステージングエリア
(Staging Area / Index)"]
    C["💾 ローカルリポジトリ
(Local Repository)"]
    D["☁️ リモートリポジトリ
(Remote Repository)"]

    A -- "git add" --> B
    B -- "git commit" --> C
    C -- "git push" --> D
    D -- "git pull" --> A

    style A fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style B fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style C fill:#FFF3E0,stroke:#FB8C00,color:#E65100
    style D fill:#F3E5F5,stroke:#8E24AA,color:#4A148C

場所	説明	関連コマンド
作業ディレクトリ	エディタで開いているファイルそのもの	─
ステージングエリア	次のコミットに含める変更を準備する場所	git add で登録
ローカルリポジトリ	コミット履歴が保存される場所	git commit で記録
リモートリポジトリ	GitHubなどの外部の共有リポジトリ	git push で送信

覚え方のコツ

「編集 → 選ぶ → 記録 → 共有」 この4ステップを意識するだけで、Git の操作がぐっと理解しやすくなります。

---

developからのcheckout

ブランチとは何か？

ブランチとは、コミット履歴の流れに付けた 「名前付きのポインタ」 です。

たとえるなら、本の 「しおり」 のようなもの。
本（コミット履歴）自体はひとつですが、しおり（ブランチ）を複数はさむことで、異なるページ（時点）から読み進めることができます。

gitGraph
    commit id: "初期コミット"
    commit id: "README追加"
    branch develop
    checkout develop
    commit id: "開発環境セットアップ"
    branch feature/login
    checkout feature/login
    commit id: "ログインページ追加"
    commit id: "バリデーション追加"

チーム開発では、main（本番環境）と develop（開発用）という2つのブランチを基本として、 作業ごとに 作業ブランチ（feature ブランチ） を作成するのが一般的です。

---

実践：作業ブランチを作成する

Step 1：最新の develop を取得する

まず、リモートの最新情報をローカルに反映させます。
これにより、他のメンバーの変更が手元に取り込まれます。

# develop ブランチに切り替え
git checkout develop

# リモートの最新を取得してマージ
git pull origin develop

よくあるミス

develop を pull せずに作業ブランチを作ると、古い状態から分岐 してしまいます。
必ず pull で最新化してからブランチを作成しましょう！

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

develop ブランチを起点に、新しい作業ブランチを作成します。

# ブランチの作成と切り替えを同時に行う（よく使う！）
git checkout -b feature/add-login-page

# ↑ 上のコマンドは以下の2つと同じ意味です
git branch feature/add-login-page    # ブランチを作成
git checkout feature/add-login-page  # ブランチを切り替え

ブランチの命名規則

チームで命名規則を統一しておくと、ブランチの目的がひと目でわかります。

プレフィックス	用途	例
feature/	新機能の追加	feature/add-login-page
fix/	バグ修正	fix/header-alignment
hotfix/	緊急の本番修正	hotfix/security-patch
chore/	雑務（設定変更など）	chore/update-dependencies

現在のブランチを確認する

今どのブランチにいるかは、いつでも確認できます。

git branch

  develop
* feature/add-login-page    ← 「*」が現在のブランチ
  main

---

git switch と git checkout の違い

Git 2.23 以降では、git switch コマンドも使えます。
checkout はブランチ切り替え以外の用途（ファイルの復元など）も兼ねているため、 ブランチ操作 専用 の switch が追加されました。

操作	checkout	switch
ブランチ切り替え	git checkout develop	git switch develop
新規作成＋切り替え	git checkout -b feature/xx	git switch -c feature/xx

ノート

本資料では広く使われている checkout で説明しますが、switch も同様に使用できます。
どちらを使うかはチームの方針に合わせましょう。

---

status / log / diff による状態確認

Git を使いこなすうえで もっとも大切な習慣 は「今の状態を確認すること」です。
コマンドを打つ前後で状態を確認するクセをつけましょう 🔍

flowchart TD
    A["✏️ ファイルを編集した"] --> B{"状態を確認しよう"}
    B --> C["git status
今どうなっている？"]
    B --> D["git diff
何が変わった？"]
    B --> E["git log
履歴はどうなっている？"]
    C --> F["変更をステージング
git add"]
    D --> F
    F --> G{"ステージング内容を確認"}
    G --> H["git diff --staged"]
    H --> I["コミット
git commit"]
    I --> E

    style A fill:#FFF9C4,stroke:#F9A825,color:#F57F17
    style C fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style D fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style E fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style F fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style I fill:#FFF3E0,stroke:#FB8C00,color:#E65100

---

git status ─ 今の状態を確認する

git status は、作業ディレクトリとステージングエリアの状態を表示します。
最も頻繁に使うコマンド です。

実践例：ファイルを編集したあとに status を確認

以下のシナリオを想定します。
login.html を 新規作成 し、style.css を 編集 した状態です。

git status

On branch feature/add-login-page
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)

        modified:   style.css

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        login.html

読み方のポイント

表示	意味	次にやること
Changes not staged for commit	編集済みだがまだ add していない	git add でステージングへ
Changes to be committed	add 済みでコミット待ち	git commit で記録
Untracked files	Git がまだ追跡していない新規ファイル	git add で追跡開始
nothing to commit	すべてコミット済みのクリーンな状態	─

短縮表示（-s オプション）

git status -s と打つと、シンプルな一覧表示になります。
慣れてきたらこちらも使ってみましょう！

記号	意味
M	変更あり（ステージング未登録）
M	ステージング登録済みの変更
A	ステージング登録済みの新規ファイル
??	新規ファイル（未追跡）

---

git log ─ コミット履歴を確認する

git log は、コミットの履歴を 新しいものから順に 表示します。
「誰が」「いつ」「何を」変更したかを確認できます。

基本表示

git log

commit a1b2c3d (HEAD -> feature/add-login-page)
Author: Taro Yamada <taro@example.com>
Date:   Fri Mar 20 10:30:00 2026 +0900

    ログインページのHTMLを追加

commit e4f5g6h (origin/develop, develop)
Author: Hanako Suzuki <hanako@example.com>
Date:   Thu Mar 19 17:00:00 2026 +0900

    ヘッダーのデザインを修正

便利なオプション

コマンド	用途
git log --oneline	各1行で簡潔に表示
git log --oneline --graph	ブランチの分岐・マージを図で表示
git log -n 5	直近の5件だけ表示
git log --author="Taro"	特定の人のコミットだけ表示
git log -- ファイル名	特定ファイルの変更履歴を表示

実践例：—oneline —graph

git log --oneline --graph --all

* a1b2c3d (HEAD -> feature/add-login-page) ログインページのHTMLを追加
* e4f5g6h (origin/develop, develop) ヘッダーのデザインを修正
* i7j8k9l トップページを作成
* m0n1o2p (origin/main, main) 初期コミット

実務でよく使うエイリアス

毎回長いオプションを打つのは手間なので、エイリアス（ショートカット） を設定すると便利です。

git config --global alias.lg "log --oneline --graph --all"

設定後は git lg と打つだけで、グラフ付き履歴を確認できます ✨

---

git diff ─ 変更内容を確認する

git diff は、具体的に 「どの行が変わったのか」 を表示します。
add / commit する前に、意図した変更だけが含まれているか確認するために使います。

3種類の diff を使い分ける

flowchart LR
    WD["🖥️ 作業ディレクトリ"]
    SA["📋 ステージング"]
    LC["💾 最新コミット"]

    WD -- "git diff" --> SA
    SA -- "git diff --staged" --> LC
    WD -- "git diff HEAD" --> LC

    style WD fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style SA fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style LC fill:#FFF3E0,stroke:#FB8C00,color:#E65100

コマンド	比較対象
git diff	作業ディレクトリ ↔ ステージングエリア
git diff --staged	ステージングエリア ↔ 最新コミット
git diff HEAD	作業ディレクトリ ↔ 最新コミット

実践例：diff の読み方

style.css に変更を加えたあとに diff を実行した例です。

git diff

diff --git a/style.css b/style.css
index 1234567..abcdefg 100644
--- a/style.css
+++ b/style.css
@@ -10,6 +10,8 @@ body {
     font-size: 16px;
 }

+.login-form {
+    max-width: 400px;
+}

記号	意味
--- a/style.css	変更前のファイル
+++ b/style.css	変更後のファイル
@@ -10,6 +10,8 @@	変更箇所（10行目付近）
+（緑）	追加された行
-（赤）	削除された行
スペース（白）	変更なし（前後の文脈表示）

diff は add する前に確認する習慣を

add してしまったあとに diff を実行しても何も表示されません（すでにステージング済みのため）。
add 後に確認する場合は git diff --staged を使いましょう。

---

add → commit → push の基本サイクル

状態確認のコマンドを学んだところで、いよいよ変更を記録して共有するフローを実践します 💪

flowchart LR
    subgraph "あなたのPC"
        A["✏️ ファイルを編集"]
        B["git add
変更をステージング"]
        C["git commit
ローカルに記録"]
    end
    subgraph "GitHub"
        D["git push
リモートに共有"]
    end

    A --> B --> C --> D

    style A fill:#FFF9C4,stroke:#F9A825,color:#F57F17
    style B fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style C fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style D fill:#F3E5F5,stroke:#8E24AA,color:#4A148C

---

Step 1：git add ─ 変更をステージングに登録

git add は、「次のコミットに含める変更」 をステージングエリアに登録するコマンドです。

基本的な使い方

# 特定のファイルをステージング
git add login.html

# 複数ファイルを指定
git add login.html style.css

# 変更のあるすべてのファイルをステージング
git add .

# 変更内容を対話的に選択してステージング（一部だけaddしたい場合）
git add -p

git add . の注意点

git add . はカレントディレクトリ以下の すべての変更 をステージングします。
意図しないファイル（デバッグ用ログ、一時ファイルなど）が含まれないよう、 add の前に git status で確認 しましょう。

.gitignore を適切に設定しておくことも重要です（第2章で詳しく解説します）。

add 後の状態確認

git add login.html style.css
git status

On branch feature/add-login-page
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

        new file:   login.html
        modified:   style.css

“Changes to be committed” に移動していれば、正しくステージングされています。
間違えた場合は git restore --staged <file> で取り消せます。

---

Step 2：git commit ─ 変更をローカルに記録

git commit は、ステージングエリアの内容を ローカルリポジトリに記録 するコマンドです。
ゲームでいう 「セーブポイント」 を作るイメージですね。

基本的な使い方

# メッセージ付きでコミット（最も一般的）
git commit -m "ログインページのHTMLとCSSを追加"

# エディタが開き、詳細なメッセージを書ける
git commit

良いコミットメッセージの書き方

コミットメッセージは 「将来の自分やチームメンバーへのメモ」 です。
何を、なぜ変更したかを簡潔に書きましょう。

✅ 良い例	❌ 悪い例
fix: パスワードリセットのメール送信エラーを修正	バグ修正した
feat: ユーザープロフィール画像のアップロード機能	作業中

Conventional Commits 形式

チームでコミットメッセージの形式を統一する場合、 Conventional Commits が広く採用されています。

プレフィックス	用途
feat:	新機能の追加
fix:	バグの修正
docs:	ドキュメントの変更
style:	コードのフォーマット変更（動作に影響なし）
refactor:	リファクタリング
chore:	ビルドや補助ツールの変更

また、リモートリポジトリがGitHubの時、 body部(コミットメッセージの3行目以降)に Closes のようなキーワードを含めてください。

1 fix: パスワードリセットのメール送信エラーを修正
2
3 Closes #17

GitHubドキュメント - プルリクエストを課題にリンクする

commit 後の確認

git commit -m "feat: ログインページのHTMLとCSSを追加"

[feature/add-login-page a1b2c3d] feat: ログインページのHTMLとCSSを追加
 2 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 login.html

git status

On branch feature/add-login-page
nothing to commit, working tree clean

git log --oneline -3

a1b2c3d (HEAD -> feature/add-login-page) feat: ログインページのHTMLとCSSを追加
e4f5g6h (origin/develop, develop) ヘッダーのデザインを修正
i7j8k9l トップページを作成

---

Step 3：git push ─ リモートに共有

git push は、ローカルリポジトリのコミットを リモートリポジトリ（GitHub）に送信 するコマンドです。
これにより、チームメンバーがあなたの変更を確認できるようになります。

初回の push（ブランチをリモートに登録）

新しく作ったブランチを初めて push する場合は、リモートにブランチを作成する必要があります。

git push --set-upstream origin feature/add-login-page

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Writing objects: 100% (3/3), 1.23 KiB | 1.23 MiB/s, done.
remote: Create a pull request for 'feature/add-login-page' on GitHub by visiting:
remote:   https://github.com/your-org/your-repo/pull/new/feature/add-login-page
* [new branch]  feature/add-login-page -> feature/add-login-page

—set-upstream (-u) の意味

このオプションは「このローカルブランチは、リモートのこのブランチと紐づいている」 という 関連（upstream） を設定します。

一度設定すれば、2回目以降は git push だけでOK です。

2回目以降の push

# upstream 設定済みなので、シンプルに push できる
git push

---

まとめ：pushまでの全体フロー

ここまでに学んだ内容を、実際の作業フローとしてまとめます 📝

flowchart TD
    S["🚀 作業開始"] --> A
    A["① git checkout develop"] --> K
    K["② git pull origin develop
developを最新化"] --> B
    B["③ git checkout -b feature/xxx
作業ブランチを作成"] --> C
    C["④ ファイルを編集
エディタで作業"] --> D
    D["⑤ git status / git diff
状態を確認"] --> E
    E["⑥ git add ファイル名
変更をステージング"] --> F
    F["⑦ git diff --staged
ステージング内容を確認"] --> G
    G["⑧ git commit -m 'メッセージ'
ローカルに記録"] --> H
    H["⑨ git log --oneline
履歴を確認"] --> I
    I["⑩ git push -u origin feature/xxx
リモートに共有"] --> J
    J["✅ 完了！PRを作成しよう"]

    style S fill:#E8EAF6,stroke:#3F51B5,color:#1A237E
    style J fill:#E8F5E9,stroke:#43A047,color:#1B5E20
    style D fill:#FFF9C4,stroke:#F9A825,color:#F57F17
    style G fill:#E3F2FD,stroke:#1E88E5,color:#0D47A1
    style I fill:#FFF3E0,stroke:#FB8C00,color:#E65100

コマンドの一気通貫

# ① develop を最新化
git checkout develop
git pull origin develop

# ② 作業ブランチを作成
git checkout -b feature/add-login-page

# ③ ファイルを編集（エディタで作業）

# ④ 状態を確認
git status
git diff

# ⑤ 変更をステージング
git add login.html style.css

# ⑥ ステージング内容を確認
git diff --staged

# ⑦ コミット
git commit -m "feat: ログインページのHTMLとCSSを追加"

# ⑧ 履歴を確認
git log --oneline -3

# ⑨ リモートに push
git push -u origin feature/add-login-page

push する前のチェックリスト

• git status で意図しない変更が残っていないか確認
• git diff --staged で commit する内容を確認
• git log --oneline で commit 履歴を確認
• コミットメッセージはわかりやすいか :::

---

コマンドリファレンス

コマンド	説明	使うタイミング
git checkout <branch>	ブランチを切り替える	作業開始時
git checkout -b <branch>	ブランチを作成して切り替え	新しい作業を始めるとき
git pull origin <branch>	リモートの最新を取得・マージ	作業開始前
git status	現在の状態を表示	常に（最も頻繁）
git log --oneline	コミット履歴を簡潔に表示	履歴確認時
git diff	未ステージの変更を表示	add 前
git diff --staged	ステージ済みの変更を表示	commit 前
git add <file>	ファイルをステージングに登録	変更確認後
git commit -m "msg"	変更をローカルに記録	ステージング確認後
git push -u origin <branch>	リモートに送信（初回）	コミット後
git push	リモートに送信（2回目以降）	コミット後

達成チェック ✅

このセクションを終えたら、以下を確認してみましょう！

• develop からブランチを作成できる
• status / log / diff の出力を読み取れる
• add → commit → push の流れを実行できる
• 各コマンドが「4つの場所」のどこに作用するか理解している

すべてチェックできたら、次のセクション 「1.2 履歴の操作と修正」 に進みましょう！ 🎉