引用django migrations文档：
每个应用程序的迁移文件都位于该应用程序内部的“migrations”目录中，并被设计为提交到其代码库并作为其代码库的一部分分发。你应该在你的开发机器上做一次，然后在你同事的机器上，你的暂存机器上，最后在你的生产机器上运行同样的迁移。
如果遵循此过程，则迁移文件中不应出现任何合并冲突。
合并版本控制分支时，仍然可能会遇到基于同一父级迁移的多个迁移的情况，例如，如果对不同开发人员同时引入了迁移。解决这种情况的一种方法是引入一个合并迁移。通常这可以通过命令自动完成

./manage.py makemigrations --merge

这将引入一个新的迁移，它依赖于当前所有的头迁移。当然，这只在头迁移之间没有冲突时有效，在这种情况下，您必须手动解决问题。
考虑到这里有些人建议您不应该将迁移提交到版本控制，我想进一步说明您应该这样做的原因。
首先，您需要应用于生产系统的迁移记录。如果将更改部署到生产环境中并希望迁移数据库，则需要对当前状态的描述。您可以为应用于每个生产数据库的迁移创建一个单独的备份，但这似乎是不必要的麻烦。
其次，迁移通常包含自定义的手写代码。它并不总是能够自动生成它们 ./manage.py makemigrations .
第三，迁移应该包括在代码评审中。它们是对您的生产系统的重大更改，并且有很多事情可能会出错。
所以简而言之，如果您关心您的生产数据，请检查您的迁移到版本控制。

您可以遵循以下流程。
你可以跑了 makemigrations 本地创建迁移文件。将此新迁移文件提交到repo。
我认为你不应该跑 makemigrations 在生产中。你可以跑了 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

引用2018年文件django 2.0(两个单独的命令= makemigrations 以及 migrate )
之所以有单独的命令来执行和应用迁移，是因为您将迁移提交到版本控制系统并随应用程序一起发布；它们不仅使您的开发更容易，而且还可供其他开发人员和生产人员使用。
https://docs.djangoproject.com/en/2.0/intro/tutorial02/

热释光；dr：提交迁移，解决迁移冲突，调整git工作流。
感觉您需要调整git工作流，而不是忽略冲突。
理想情况下，每个新特性都在不同的分支中开发，并与拉请求合并。
如果存在冲突，prs就不能被合并，因此需要合并其特性的用户需要解决冲突，包括迁移。这可能需要不同团队之间的协调。
但提交迁移文件很重要！如果发生冲突，django甚至可以帮助您解决这些冲突；）

我无法想象为什么会有冲突，除非你在编辑迁移？这通常会导致糟糕的结果——如果有人错过了一些中间提交，那么他们将无法从正确的版本升级，并且他们的数据库副本将被损坏。
我遵循的过程非常简单—每当您更改应用程序的模型时，您也会提交迁移，然后迁移不会更改—如果您需要模型中的其他内容，那么您会更改模型并在更改的同时提交新的迁移。
在greenfield项目中，您通常可以删除迁移，并在发布时从头开始进行0001\迁移，但如果您有生产代码，则不能（尽管您可以将迁移压缩为一个）。

通常使用的解决方案是，在将任何内容合并到master之前，开发人员必须提取任何远程更改。如果迁移版本中存在冲突，他应该将本地迁移（远程迁移已经由其他开发人员运行，并且可能已经在生产中运行）重命名为n+1。
在开发过程中，不提交迁移是可以的（但是不要添加忽略，只是不要提交） add 他们）。但是一旦投入生产，就需要它们来保持模式与模型更改的同步。
然后需要编辑文件，并更改 dependencies 到最新的远程版本。
这适用于django迁移，以及其他类似的应用程序（sqlalchemy+alembic、ror等）。

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

如果您有单独的数据库用于开发、暂存和生产环境，那么可以忽略迁移。出于开发目的，您可以使用本地sqlite db并在本地进行迁移。我建议您再创建四个分支：
没有迁移的主清理新代码。没有人与这个分支机构有联系。仅用于代码检查
发展-日常发展。接受推/拉。每个开发人员都在使用sqlite数据库
cloud_dev_env-远程云/服务器开发环境。只拉。将迁移保持在本地计算机上，用于dev数据库的代码部署和远程迁移
cloud_stag_env-远程云/服务器stag环境。只拉。将迁移保持在本地计算机上，用于stag数据库的代码部署和远程迁移
cloud\u prod\u env-远程云/服务器开发环境。只拉。将迁移保持在本地计算机上，用于prod数据库的代码部署和远程迁移
注意：2，3，4-迁移可以保存在repos中，但是pull请求合并应该有严格的规则，所以我们决定找一个人负责部署，所以唯一拥有所有迁移文件的人-我们的部署人员。每次我们对模型进行任何更改时，他都会保留远程数据库迁移。

简而言之，我建议在回购协议中排除迁移。代码合并后，只需运行 ./manage.py makemigrations 你们都准备好了。
我认为你不应该把迁移文件放到repo中。它会破坏其他人的开发环境和其他产品和阶段环境中的迁移状态(有关示例，请参阅sugar tang的评论）。
在我看来，django迁移的目的是找出以前模型状态和新模型状态之间的差距，然后将差距序列化。如果您的模型在代码合并后发生更改，您可以简单地执行以下操作 makemigrations 找出差距。当您可以自动且无bug地实现相同的迁移时，为什么要手动并小心地合并其他迁移？django文件说，
它们（迁移）的设计基本上是自动的
; 请保持这样。要手动合并迁移，您必须完全了解其他人更改了什么以及更改的依赖性。这是一个很大的开销和容易出错。所以跟踪模型文件就足够了。
这是一个关于工作流的好主题。我有其他选择。