Question

目前我正在使用庞大的rails应用程序和多个分支，每个分支都有一个针对此应用程序的新功能。它发生了很多功能需要迁移，在将它与master合并之前应该不会出现问题：schema.rb已经使用dev数据库的信息进行了更新！

澄清：

1. Branch A has migration create_table_x
2. Branch B has migration create_table_y
3. Branch A adds another create_table_z and runs db:migrate
4. You want to merge Branch A with Master and you see table_x, table_y and table_z in the schema.rb of Branch A.

在分支中的每次迁移之前重置+种子数据库或为每个分支创建数据库都不是一个选项。由于2 GB SQL数据的巨大规模，它将无法使用。

我的问题：

是否真的需要将schema.rb保留在存储库中，因为每次迁移都会重建它？

如果是这样，是否可以从迁移而不是数据库转储构建模式？

Answer 1

您应该在您的仓库中保留架构。运行迁移将修复schema.rb文件中的合并冲突。我简单地回答你的问题

是必需的吗？不是真的，而是良好的做法。

“强烈建议您将此文件检入您的版本控制系统。“-schema.rb

有可能吗？是的，但您可能想问自己是否真的通过这样做来节省任何时间，无论是手动还是从其他地方的迁移中构建模式并将其推入。

您可以使用

rake db:schema:load

和

rake db:schema:dump

http://tbaggery.com/2010/10/24/reduce-your-rails-schema-conflicts.html

Answer 2

将schema.rb保留在repo中非常重要，因为您希望新开发人员（或您的测试环境）能够仅从schema.rb生成新数据库。当您进行大量迁移时，它们可能不会全部继续运行，尤其是当它们依赖于不存在，或已更改的模型类，或者具有与首次运行迁移时不同的验证时。运行测试时，您希望从schema.rb转储并重新创建数据库，而不是每次运行完整的测试套件时重新运行所有迁移。

如果您同时处理两个不同的功能分支，并在两者中更改数据库结构，我认为schema.rb是您遇到的问题中最少的。如果重命名或删除分支B中的列，则只要引用旧列，分支A就会中断。如果他们所做的只是创建新表，那就不是那么糟糕，但是当你从master合并到A时，想要 schema.rb更新，这样A就不会尝试运行第二次迁移失败，因为新表已经存在。

如果这不能回答你的问题，也许你可以再解释一下你的工作流程了吗？

Answer 3

Fresh Temporary DB作为快速解决方法

例如，在特定分支上需要漂亮db/schema.rb时，请执行以下操作：

git checkout - db / schema.rb
切换到不同的开发数据库，即更新config / database.yml
rake db：drop＆amp;＆amp; rake db：setup
rake db：migrate
提交你的漂亮的db / schema.rb
还原config / database.yaml

schema.rb由于其他分支中的迁移而搞砸了

3 个答案: