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

希望这能帮助到一些人。

您可以遵循以下流程。

您可以在本地运行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

引用Django迁移文档:

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

如果您遵循这个过程，您应该不会在迁移文件中遇到任何合并冲突。

当合并版本控制分支时，您仍然可能遇到基于同一个父迁移的多个迁移的情况，例如，如果不同的开发人员同时引入了一个迁移。解决这种情况的一种方法是引入merge_migration。这通常可以通过命令自动完成

./manage.py makemigrations --merge

这将引入一个新的迁移，它依赖于所有当前的头部迁移。当然，这只在头部迁移之间没有冲突的情况下才有效，在这种情况下，您必须手动解决问题。

鉴于这里有些人建议您不应该将您的迁移提交给版本控制，我想详细说明为什么您实际上应该这样做。

首先，您需要应用到生产系统的迁移的记录。如果将更改部署到生产环境，并希望迁移数据库，则需要对当前状态进行描述。您可以为应用于每个生产数据库的迁移创建单独的备份，但这似乎不必要地麻烦。

第二，迁移通常包含自定义的手写代码。使用./manage.py makemigrations并不总是能够自动生成它们。

第三，迁移应该包括在代码评审中。它们是对您的生产系统的重大更改，并且有许多事情可能会出错。

因此，简而言之，如果您关心您的生产数据，请检查您到版本控制的迁移。

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

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

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

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

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

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

Gitignore迁移，如果你有独立的db用于开发，分期和生产环境。出于开发目的，您可以使用本地sqlite DB并在本地进行迁移。 我建议你创建四个额外的分支:

Master - Clean fresh code without migrations. Nobody is connected to this branch. Used for code reviews only Development - daily development. Push/pull accepted. Each developer is working on sqlite DB Cloud_DEV_env - remote cloud/server DEV environment. Pull only. Keep migrations locally on machine, which is used for the code deployment and remote migrations of Dev database Cloud_STAG_env - remote cloud/server STAG environment. Pull only. Keep migrations locally on machine, which is used for the code deployment and remote migrations of Stag database Cloud_PROD_env - remote cloud/server DEV environment. Pull only. Keep migrations locally on machine, which is used for the code deployment and remote migrations of Prod database

注: 2、3、4——迁移可以保存在回购中，但是应该有严格的pull请求合并规则，所以我们决定找一个人来负责部署，所以唯一一个拥有所有迁移文件的人——我们的部署人员。每当我们在模型中有任何变化时，他都会保持远程DB迁移。