引用自2022年的Django 4.0文档。(两个单独的命令= makemigrations和migrate)

为什么要创建和应用单独的命令 迁移是因为您将向版本控制提交迁移 将它们整合到你的应用中;他们不仅让你 开发更容易，它们也可以被其他开发人员使用 生产。

https://docs.djangoproject.com/en/4.0/intro/tutorial02/

您可以遵循以下流程。

您可以在本地运行makemigrations，这将创建迁移文件。将这个新的迁移文件提交到repo。

在我看来，你根本不应该在生产中进行大规模移民。您可以在生产环境中运行migrate，您将看到从本地提交的迁移文件应用了迁移。这样可以避免所有的冲突。

在LOCAL ENV中，要创建迁移文件，

python manage.py makemigrations 
python manage.py migrate

现在提交这些新创建的文件，如下所示。

git add app/migrations/...
git commit -m 'add migration files' app/migrations/...

在PRODUCTION ENV中，只执行以下命令。

python manage.py migrate

引用自2022年的Django 4.0文档。(两个单独的命令= makemigrations和migrate)

为什么要创建和应用单独的命令 迁移是因为您将向版本控制提交迁移 将它们整合到你的应用中;他们不仅让你 开发更容易，它们也可以被其他开发人员使用 生产。

https://docs.djangoproject.com/en/4.0/intro/tutorial02/

您应该将迁移视为数据库模式的版本控制系统。Makemigrations负责将模型更改打包到单独的迁移文件中(类似于提交)，migrate负责将这些文件应用到数据库中。

每个应用程序的迁移文件都存在于该应用程序内部的“migrations”目录中，并被设计为提交并作为其代码库的一部分分发。您应该在您的开发机器上进行一次迁移，然后在您同事的机器、登台机器以及最终的生产机器上运行相同的迁移。

黄金法则:在开发中只做一次，然后移植到所有开发中

在git中有一堆迁移文件是很混乱的。迁移文件夹中只有一个文件不应该忽略。该文件是init.py文件，如果忽略它，python将不再在目录中查找子模块，因此任何导入模块的尝试都会失败。所以问题应该是如何忽略除了init.py之外的所有迁移文件? 解决方案是: 将“0*.py”添加到.gitignore文件中，它可以完美地完成工作。

希望这能帮助到一些人。

通常使用的解决方案是，在将任何内容合并到master之前，开发人员必须提取任何远程更改。如果在迁移版本中存在冲突，他应该将本地迁移(远程迁移已经由其他开发人员运行，并且可能已经在生产中运行)重命名为N+1。

在开发过程中，不提交迁移是可以的(但是不要添加忽略，不要添加它们)。但是一旦进入生产环境，您将需要它们来保持模式与模型更改同步。

然后需要编辑该文件，并将依赖项更改为最新的远程版本。

这适用于Django迁移，以及其他类似的应用程序(sqlalchemy+alembic, RoR等)。