Answers:
引用Django迁移文档：
每个应用程序的迁移文件都位于该应用程序内的“迁移”目录中，并被设计为提交至其代码库并作为其代码库的一部分进行分发。您应该在开发计算机上制作一次，然后在同事的计算机，登台计算机以及最终的生产计算机上运行相同的迁移。
如果遵循此过程，则迁移文件中不会出现任何合并冲突。
合并版本控制分支时，您仍然可能会遇到基于同一父级迁移的多个迁移的情况，例如，如果不同的开发人员同时引入了迁移。解决这种情况的一种方法是引入_merge_migration_。通常这可以通过以下命令自动完成
./manage.py makemigrations --merge这将引入一个新的迁移，该迁移取决于当前的所有head迁移。当然，这仅在磁头迁移之间没有冲突时才有效，在这种情况下，您将必须手动解决问题。
鉴于这里有人建议您不要将迁移提交到版本控制，因此我想详细说明为什么您应该这样做。
首先，您需要记录应用于生产系统的迁移。如果将更改部署到生产中并想迁移数据库，则需要描述当前状态。您可以为应用到每个生产数据库的迁移创建单独的备份，但这似乎不必要。
其次，迁移通常包含自定义的手写代码。并非总是可以使用自动生成它们./manage.py makemigrations。
第三，迁移应包含在代码审查中。它们是对您的生产系统的重大更改，很多事情都可能出错。
简而言之，如果您关心生产数据，请检查您向版本控制的迁移。
您可以按照以下过程进行操作。
您可以在makemigrations本地运行，这将创建迁移文件。提交此新的迁移文件以回购。
我认为您根本不应该makemigrations投入生产。您可以migrate在生产环境中运行，并且会看到从您从本地提交的迁移文件中应用了迁移。这样您可以避免所有冲突。
在本地环境中，要创建迁移文件，
python manage.py makemigrations
python manage.py migrate现在提交这些新创建的文件，如下所示。
git add app/migrations/...
git commit -m 'add migration files' app/migrations/...在生产环境中，仅运行以下命令。
python manage.py migratemigrate，决不makemigrations要进行已提交的迁移。没想到。
引用2018年文档Django 2.0。（两个单独的命令= makemigrations和migrate）
之所以有单独的命令来进行和应用迁移，是因为您会将迁移提交到版本控制系统，并随应用程序一起交付；它们不仅使您的开发更加容易，而且还可以被其他开发人员和生产环境使用。
TL; DR：提交迁移，解决迁移冲突，调整git工作流程。
感觉就像您需要调整git工作流程，而不是忽略冲突。
理想情况下，每个新功能都在不同的分支中开发，并与拉取请求合并回去。
如果存在冲突，则无法合并PR，因此需要合并其功能的人员需要解决冲突，包括迁移。这可能需要不同团队之间的协调。
提交迁移文件很重要！如果发生冲突，Django甚至可以帮助您解决那些冲突 ;）
在git中有一堆迁移文件很麻烦。迁移文件夹中只有一个文件，您不应忽略。该文件是init .py文件，如果忽略它，python将不再在目录内寻找子模块，因此任何导入模块的尝试都会失败。所以问题应该怎么忽略所有迁移文件，但初始化的.py？解决方案是：将'0 * .py'添加到.gitignore文件中，即可完美完成工作。
希望这对某人有帮助。
如果您具有用于开发，登台和生产环境的单独的数据库，则忽略迁移。对于开发人员。目的您可以使用本地sqlite DB并在本地进行迁移。我建议您另外创建四个分支：
主-清除新代码而不进行迁移。没有人连接到该分支。仅用于代码审查
开发-日常开发。接受推/拉。每个开发人员都在使用sqlite DB
Cloud_DEV_env-远程云/服务器DEV环境。只拉。将迁移保留在本地计算机上，用于代码部署和Dev数据库的远程迁移
Cloud_STAG_env-远程云/服务器STAG环境。只拉。将迁移保留在本地计算机上，该迁移用于Stag数据库的代码部署和远程迁移
Cloud_PROD_env-远程云/服务器DEV环境。只拉。将迁移保留在本地计算机上，该迁移用于Prod数据库的代码部署和远程迁移
注意：2、3、4-迁移可以保存在存储库中，但是应该有合并合并拉取请求的严格规则，因此我们决定找一个负责部署的人员，所以唯一拥有所有迁移文件的人-我们的部署-嗯 每当我们对模型进行任何更改时，他都会保留远程数据库迁移。
简短答案
我建议排除回购中的迁移。代码合并后，只需运行即可./manage.py makemigrations。
长答案 我不认为您应该将迁移文件放入存储库中。它将破坏其他人的开发环境以及其他产品和阶段环境中的迁移状态。（有关示例，请参见Sugar Tang的评论）。
以我的观点，Django迁移的目的是找到先前模型状态和新模型状态之间的差距，然后序列化该差距。如果您的模型在代码合并后发生更改，则可以简单makemigrations地找出差距。当您可以自动实现相同且无错误的迁移时，为什么要手动仔细合并其他迁移？Django文档说，
它们*（迁移）*被设计为自动的
; 请保持这种方式。要手动合并迁移，您必须完全了解其他更改和更改的任何依存关系。这会产生很多开销，而且容易出错。因此，跟踪模型文件就足够了。
这是工作流程中的一个好话题。我愿意接受其他选择。
manage.py makemigrations --merge对我来说是完全自动的。
makemigrations some_app，则不仅会影响该成员控制下的模型，而且也会影响其他相关模型。也就是说，其他应用程序中的迁移文件（00 * _ *）将被更改。这会导致在向GitHub推送或从GitHub推送时出现许多冲突问题。由于当前我们的系统尚未准备好投入生产，因此我们仅提供.gitignore迁移文件。当系统投入生产时，我们仍然不知道如何解决。有人有解决方案吗？