makemigrations frente a migrate

Django changes your database in two steps: first it writes a plan, then it runs that plan. Knowing which is which saves a lot of confusion. 🧭

makemigrations looks at your models, spots what changed, and writes a migration file describing the change. It does not touch the database yet.

migrate takes those migration files and actually runs them against the database, creating or altering real tables.

Splitting plan from action lets you review a change, commit it to git, and apply the exact same steps on every machine and server.

Each plan lives as a file in your app under migrations/. You commit these files so teammates apply identical changes.

Edit a model, run makemigrations to record it, then run migrate to apply it. That loop is your everyday schema workflow.

Add a clear label so files read like a history, not a pile of numbers. Use the --name flag to describe what changed.

Pass an app label to generate or apply migrations for just that app, keeping unrelated changes out of the way.

Run makemigrations with --check in CI to fail the build if a model change has no matching migration yet.

The showmigrations command lists every migration and marks the applied ones with an X, so you know your exact state.

Always makemigrations first, then migrate. Running migrate alone applies whatever plans already exist, including Django built-ins.

Which command actually changes the database tables?

You learned the rhythm: makemigrations writes the plan, migrate applies it. Plan first, apply second, and your schema stays in sync everywhere. 🎉