マイグレーション ― makemigrations と migrate

導入

このコースでは schema_editor.create_model(...) で手動で表を作っていました。本物のプロジェクトでは、この作業を マイグレーション が自動でやってくれます。モデルの変更をデータベースに反映する、Django の重要な仕組みです。

説明

マイグレーションは「モデルの設計図の変更履歴」です。流れはこうです。

flowchart LR
  M["models.py を編集<br/>（フィールド追加など）"] --> MM["makemigrations<br/>変更を検出して<br/>移行ファイルを生成"]
  MM --> F["0001_initial.py<br/>0002_add_field.py …"]
  F --> MG["migrate<br/>データベースに適用"]
  MG --> DB[("データベース")]

使うコマンドは2つだけです。

# ① モデルの変更を「移行ファイル」に書き出す
python manage.py makemigrations

# ② 移行ファイルをデータベースに適用する（表の作成・変更）
python manage.py migrate

makemigrations … models.py と現状の差分を検出し、blog/migrations/0001_initial.py のような Python ファイルを生成します。「この表を作る」「この列を足す」といった手順が記録されます。
migrate … 未適用の移行ファイルを順に実行し、実際のデータベースを変更します。

たとえば Post に published フィールドを足したら、もう一度 makemigrations（0002_... が生成される）→ migrate するだけ。SQL を手で書く必要はありません。

マイグレーションの利点：

履歴が残る … いつ・どんな変更をしたかが Git で追える。
チームで共有できる … 移行ファイルを共有すれば、全員のデータベースを同じ状態にできる。
本番へ安全に反映 … 本番サーバーでも migrate を1回流すだけで、開発と同じ構造になる。

最初にプロジェクトを作ったら、まず migrate を実行します。これで Django が標準で使う認証（auth）や管理サイト用の表が作られます。

python manage.py migrate           # 最初の1回（標準アプリの表を作成）
python manage.py createsuperuser   # 管理者ユーザーを作る（次章の admin で使う）

このコースの schema_editor.create_model(...) は、この migrate が裏でやっていることを、学習用に手動で1回だけ行っているものだと考えてください。本物のプロジェクトでは書きません。