我应该在.gitignore文件中添加Django迁移文件吗？

Question

我应该在.gitignore文件中添加Django迁移文件吗？

由于迁移冲突，我最近收到了很多git问题，并且想知道我是否应该将迁移文件标记为忽略。

如果是这样，我将如何添加我在应用中的所有迁移，并将其添加到.gitignore文件中？

Answer 1

引用Django migrations documentation：

  

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

如果您遵循此过程，则不应在迁移文件中收到任何合并冲突。

要缓解您当前遇到的任何问题，您应指定哪个存储库或分支具有迁移文件的权威版本，然后使用git's attribute mechanism指定合并策略＆＃34;我们的＆＃34;对于这些文件。这将告诉git始终忽略对这些文件的外部更改，而更喜欢本地版本。

Answer 2

没有

我已经多次这样做过了，在我的生活中，我找不到需要在回购中迁移的案例。

正如我所看到的，架构的最终记录是models.py。如果我合并了某个更改而其他人提取了该更改，那么当它们运行makemigrations和migrate时，所有更改都将是正确的。没有必要确定＆＃34;我们＆＃34;的策略是什么？是为了迁移。

如果我们需要回滚，那么我们还原models并迁移。一切都好，没有问题。

没有抱怨某个字段已经存在等等。

我想知道是否有人可以给我一个特定的案例，在我开始工作之前必须合并另一个开发人员的迁移文件是一个优势。我知道文档说我应该，所以我认为它是如此。但我甚至从未遇到过。

任何？

Answer 3

您可以按照以下流程进行操作。

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

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

IN LOCAL ENV ，创建迁移文件，

python manage.py makemigrations 
python manage.py migrate

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

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

IN PRODUCTION ENV ，只运行以下命令。

python manage.py migrate

Answer 4

引用2018年的文档，Django 2.0。 （两个单独的命令= makemigrations和migrate）

  

有单独的命令可以制作和应用的原因   迁移是因为您将提交迁移到版本控制   系统并与您的应用程序一起发货;他们不仅让你的   开发更容易，它们也可供其他开发人员使用   生产

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

Answer 5

我无法想象为什么你会遇到冲突，除非你以某种方式编辑迁移？这通常会很糟糕 - 如果有人错过了某些中间提交，那么他们就不会从正确的版本升级，而且他们的数据库副本也会被破坏。

我遵循的流程非常简单 - 每当您更改应用的模型时，您还会提交迁移，然后迁移不会更改 - 如果您需要更改模型，然后您更改模型并在更改后提交新的迁移。

在绿地项目中，您经常可以删除迁移，并在发布时通过0001_迁移从头开始，但如果您有生产代码，则不能（尽管您可以将迁移压缩为一个）。 / p>

Answer 6

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

在开发过程中，可能没有提交迁移（不要添加忽略，只是不要add它们）。但是，一旦您投入生产，您就需要它们以使架构与模型更改保持同步。

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

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

Answer 7

您应该将迁移视为数据库架构的版本控制系统。 ma​​kemigrations 负责将您的模型更改打包到单独的迁移文件中（类似于提交），而 migrate 负责将这些更改应用到您的数据库中。

每个应用的迁移文件都位于该应用内的“迁移”目录中，并且旨在提交到其代码库并作为其代码库的一部分分发。您应该在开发机器上进行一次迁移，然后在同事的机器、临时机器上运行相同的迁移，最终在生产机器上运行。

黄金法则：开发一次，全部迁移

Answer 8

感觉您需要调整 git 工作流程，而不是忽略冲突。

理想情况下，每个新功能都是在不同的分支中开发的，并与拉取请求合并。

如果发生冲突，PR无法合并，因此需要合并其功能需求来解决冲突，包括迁移。

Answer 9

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

答案很长 我不认为您应该将迁移文件放入repo。它将破坏其他人的开发环境和其他产品和舞台环境中的迁移状态。 （请参阅Sugar Tang的评论中的例子）。

在我看来，Django迁移的目的是找到先前模型状态和新模型状态之间的差距，然后将差距序列化。如果您的模型在代码合并后发生变化，您可以简单地makemigrations找出差距。当您可以自动实现相同的迁移并且没有bug时，为什么还要手动并仔细地合并其他迁移？ Django documentation说，

  

他们*（迁移）*'主要设计为自动

请保持这种方式。要手动合并迁移，您必须完全了解其他人已更改的内容以及对更改的依赖性。这有很多开销和容易出错的问题。因此跟踪模型文件就足够了。

这是关于工作流程的一个很好的主题。我对其他选择持开放态度。

Answer 10

在git中有一堆迁移文件很麻烦。迁移文件夹中只有一个文件，您不应忽略。该文件是 init .py文件，如果您忽略它，python将不再在目录内寻找子模块，因此任何导入模块的尝试均将失败。因此，问题应该是如何忽略除 init .py之外的所有迁移文件？ 解决方案是： 将'0 * .py'添加到.gitignore文件中，即可完美完成工作。

希望这对某人有帮助。

Answer 11

如果您具有用于开发，登台和生产环境的单独的数据库，则忽略迁移。对于开发人员。目的您可以使用本地sqlite DB并在本地进行迁移。 我建议您另外创建四个分支：

1. 主站-无需迁移即可清除新代码。没有人连接到该分支。仅用于代码审查

2. 发展-日常发展。接受推/拉。每个开发人员都在开发sqlite DB

3. Cloud_DEV_env-远程云/服务器DEV环境。只拉。将迁移保持在本地计算机上，该迁移用于代码部署和Dev数据库的远程迁移

4. Cloud_STAG_env-远程云/服务器STAG环境。只拉。将迁移保留在本地计算机上，该迁移用于Stag数据库的代码部署和远程迁移

5. Cloud_PROD_env-远程云/服务器DEV环境。只拉。将迁移保持在本地计算机上，该迁移用于Prod数据库的代码部署和远程迁移

注意： 2、3、4-迁移可以保存在存储库中，但是应该有合并合并拉取请求的严格规则，因此我们决定找一个负责部署的人员，以便唯一拥有所有迁移文件的人-我们的部署人员。每当我们对模型进行任何更改时，他都会保持远程数据库迁移。