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

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

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

简短的回答 我建议在回购中排除迁移。代码合并后，只需运行./manage.py makemigrations，就可以完成所有设置。

长回答 我认为您不应该将迁移文件放入repo。它会破坏在别人的开发环境和其他刺激和阶段环境中的迁移状态。(举例请参考Sugar Tang的评论)。

在我看来，Django迁移的目的是找到以前的模型状态和新的模型状态之间的差距，然后序列化这个差距。如果你的模型在代码合并后发生了变化，你可以简单地做makemigrationations来找出差距。当您可以自动且无错误地完成相同的迁移时，为什么还要手动且仔细地合并其他迁移呢?Django文档说，

他们*(迁移)*被设计成大部分是自动的

； 请保持这样。要手动合并迁移，您必须完全理解其他人更改了什么以及更改的依赖性。这是很大的开销，而且很容易出错。因此跟踪模型文件就足够了。

这是关于工作流的一个很好的主题。我愿意接受其他选择。

提交迁移只会导致灾难。因为迁移在某种程度上是一条可以追溯的链，如果你有来自以前迁移的依赖，例如pip模块，你在项目生命周期的某个时刻使用过，然后停止使用。您可能会在迁移线程中发现这样的依赖关系，并且必须手动从迁移文件中删除这些导入。

结论，除非你是Django的神级开发者，否则最好避免在提交时添加迁移。

您可以遵循以下流程。

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

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

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

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

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

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迁移。