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

小开

最佳答案

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

如果您遵循这个过程，您应该不会在迁移文件中遇到任何合并冲突。

当合并版本控制分支时，您仍然可能遇到基于同一个父迁移的多个迁移的情况，例如，如果不同的开发人员同时引入了一个迁移。解决这种情况的一种方法是引入merge_migration。这通常可以通过命令自动完成

./manage.py makemigrations --merge

这将引入一个新的迁移，它依赖于所有当前的头部迁移。当然，这只在头部迁移之间没有冲突的情况下才有效，在这种情况下，您必须手动解决问题。

鉴于这里有人建议你不应该提交你的迁移到版本控制，我想详细说明为什么你实际上应该这样做。

首先，您需要应用到生产系统的迁移的记录。如果将更改部署到生产环境，并希望迁移数据库，则需要对当前状态进行描述。您可以为应用于每个生产数据库的迁移创建单独的备份，但这似乎不必要地麻烦。

第二，迁移通常包含自定义的手写代码。并不总是可以用./manage.py makemigrations自动生成它们。

第三，迁移应该包括在代码评审中。它们是对您的生产系统的重大更改，并且有许多事情可能会出错。

因此，简而言之，如果您关心您的生产数据，请检查您到版本控制的迁移。

小开

DR:提交迁移，解决迁移冲突，调整git工作流程。

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

理想情况下，每个新特性都在不同的分支中开发，并与把请求合并。

如果有冲突，pr就不能合并，因此需要合并他的特性的人需要解决冲突，包括迁移。这可能需要不同团队之间的协调。

提交迁移文件是很重要的!如果出现冲突，Django甚至可以帮助您解决这些冲突;)

小开

我无法想象为什么你会得到冲突，除非你以某种方式编辑迁移?这通常会以糟糕的结果结束——如果有人错过了一些中间提交，那么他们将无法从正确的版本升级，并且他们的数据库副本将被损坏。

我遵循的过程非常简单——每当你改变一个应用程序的模型时，你也要提交一个迁移，然后这种迁移不会改变——如果你需要模型中有不同的东西，那么你改变模型，并在你的更改中提交一个新的迁移。

在未开发的项目中，当你发布时，你通常可以删除迁移，然后用0001_迁移从头开始，但如果你有生产代码，那么你不能(尽管你可以把迁移压缩成一个)。

小开

您可以遵循以下流程。

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

在我看来，你根本不应该在生产环境中运行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 migrate

小开

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

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

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

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

小开

< >强简短的回答我建议在回购中排除迁移。代码合并后，只需运行./manage.py makemigrations，你就全部设置好了

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

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

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

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

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

小开

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

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

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

小开

在git中有一堆迁移文件是很混乱的。迁移文件夹中只有一个文件不应该忽略。该文件是初始化.py文件，如果忽略它，python将不再在目录中查找子模块，因此任何导入模块的尝试都会失败。所以问题应该是如何忽略除初始化.py之外的所有迁移文件? 解决方案是: 将“0*.py”添加到.gitignore文件中，它可以完美地完成工作。< / p >

希望这能帮助到一些人。

小开

Gitignore迁移，如果你有独立的db用于开发，分期和生产环境。出于开发目的，您可以使用本地sqlite DB并在本地进行迁移。我建议你创建四个额外的分支:

Master -没有迁移的干净的新代码。没有人与这个部门有联系。仅用于代码审查

发展——日常发展。推/拉接受。每个开发人员都在sqlite DB上工作

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

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

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

< p >指出: 2、3、4——迁移可以保存在回购中，但是应该有严格的pull请求合并规则，所以我们决定找一个人来负责部署，所以唯一一个拥有所有迁移文件的人——我们的部署人员。每次我们在模型中有任何变化时，他都会保留远程DB迁移

小开

您应该将迁移视为数据库模式的版本控制系统。makemigrations负责将你的模型更改打包到单独的迁移文件中——类似于提交——而migrate负责将这些文件应用到你的数据库中。

每个应用程序的迁移文件位于该应用程序内部的“migrations”目录中，并为承诺而设计到其代码库，并作为其代码库的一部分分发。您应该在您的开发机器上进行一次迁移，然后在您同事的机器、登台机器以及最终的生产机器上运行相同的迁移。

黄金法则:在开发中只做一次，然后移植到所有开发中