Exercise 3: Why Migrations Are Two Separate Commands — Possible Solution ==================================================================== WHAT makemigrations DOES ------------------------------ makemigrations compares the current state of the models against the last recorded schema state and generates a migration file - a versioned, reviewable Python description of exactly what changed (a new field, an altered column type, and so on). It does not touch the actual database at all; it only produces a file describing the change. WHAT migrate DOES ------------------------------ migrate is the separate step that actually applies any pending migration files to a real database, executing the schema changes those files describe. WHY THEY'RE KEPT SEPARATE ------------------------------ Splitting "describe the change" from "apply the change" into two distinct commands means a generated migration file can be reviewed, read, and committed to version control before it's ever run against any real database. It also means the exact same migration file can be applied identically across a developer's own machine, a staging environment, and production, rather than each environment independently trying to infer what schema change should happen - a single, explicit artifact travels through every environment instead. WHY THIS WORKS AS AN ANSWER ------------------------------ It correctly distinguishes makemigrations (generating a reviewable description of the change) from migrate (actually applying it to a database), and correctly explains that keeping them separate enables reviewing migrations before they run and applying the identical change consistently across multiple environments.