Django：合并迁移冲突的最佳方法

Posted 2023-02-24

【中文标题】Django：合并迁移冲突的最佳方法

【英文标题】：Django: Best way to merge migrations conflicts

【发布时间】：2018-04-16 06:36:42

【问题描述】：

我目前正在开发一个 dev 分支，有一天我需要将它合并到 master。我的 dev 分支上最多有 20 个迁移文件，而 master 上的数量大致相同。我需要在两个分支上进行迁移，这将导致迁移具有相同的前缀，

（例如0003_auto）

换句话说，如果您有由makemigrations 生成的具有相同前缀的迁移文件，那么处理此问题的最佳/安全方法是什么。

以下是我认为自己的两种方式（可能完全错误）：

删除所有迁移文件，合并代码，然后运行新的makemigrations 和migrate，这将导致只有一个迁移文件。

使用--merge 标志让django 进行合并：

makemigrations --merge

现在，知道了这一切，我想知道处理这个问题的最佳方法是什么。一般来说，我应该使用什么来正确合并冲突并在每次模型更新时为我提供一个新版本的项目。

编辑

我认为提供逐步解决方案对我和未来的用户来说是理想的，因为存在大量关于该主题的信息，但似乎没有一个是简洁明了的。

【问题讨论】：

你有生产数据库吗？你在用 git 吗？

我仍处于项目的开发阶段。但是最好不要删除数据库，是的，我正在使用 git。

另外，这是我目前的情况，但总的来说，我正在寻找一种简单的方法来做到这一点。我多次查看文档，但找不到处理迁移的简单方法正如我所说，我发现的唯一简单方法是--merge，但这足够了吗？

这是来自 Django 官方文档：每个应用程序的迁移文件都位于该应用程序内部的“迁移”目录中，旨在提交并作为其一部分分发，它的代码库。您应该在您的开发机器上进行一次迁移，然后在您同事的机器、暂存机器以及最终的生产机器上运行相同的迁移。

不幸的是，您在这些 cmets 中得到了一些非常糟糕的建议。正如文档所说，迁移是您代码库的一部分，必须致力于版本控制和部署。您不得在生产环境中运行 makemigrations。

【参考方案1】：

您可以使用django-migration-fixer 解决迁移错误

可以使用

在您的开发分支上修复迁移

$ git checkout [dev-branch]
$ git merge [main/master]

按照安装说明here

运行

$ python manage.py makemigrations --fix -b [main/master]

提交更改并推送到远程分支

$ git add .
$ git commit -am ...
$ git push ...

【参考方案2】：

不用担心的最简单的方法是：

恢复到稳定点（冲突前）：

python manage.py migrate usersmaster 0021_signup_status

删除新的迁移文件。

重新进行迁移：

python manage.py makemigrations

【讨论】：

makemigrations 可能会创建在第 2 步中删除的相同文件。这意味着您可以省略第 2 步和第 3 步。此外，可以手动编写新的迁移文件。

【参考方案3】：

来自Django docs：

由于迁移存储在版本控制中，您偶尔会遇到这样的情况：您和另一位开发人员同时向同一个应用提交了迁移，导致两次迁移的编号相同。

别担心 - 这些数字仅供开发人员参考，Django 只关心每个迁移有不同的名称 [强调添加]。

【讨论】：

数字和文件名无关紧要，但两个文件将指向相同的先前迁移（依赖项部分）。

是的，毫不奇怪，确保没有冲突是您的责任，但问题不在于冲突或解决冲突。

【参考方案4】：

当你准备好后，你应该从 master 合并到你的 development 分支。那时你应该修复所有的冲突，你的迁移应该在 master 的迁移之后进行，毕竟你的数据库应该看起来像你想要的那样。

由于这个过程需要时间，而且相当痛苦，大多数人会考虑短命的开发分支。这样，您需要一次处理一两个迁移文件。