由于其他分支的迁移，schema.rb 搞砸了答案

【问题标题】：schema.rb messed up due to migrations in other branches由于其他分支的迁移，schema.rb 搞砸了
【发布时间】：2013-05-08 07:08:54
【问题描述】：

目前，我正在使用一个巨大的 rails 应用程序和多个分支，每个分支都有此应用程序的新功能。经常发生需要迁移的功能，在您将其与 master 合并之前，这应该不是问题：schema.rb 已使用您的开发数据库的信息进行了更新！

澄清一下：

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 保留在存储库中，因为每次迁移都会重新构建它？

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

【问题讨论】：

我认为您应该将 schema.rb 保存在您的存储库中。可能会发生，有人清理了迁移文件并删除了一些过去未使用的迁移......如果你没有统一的 schema.rb，我最终可能会一团糟。每次迁移都会更新架构文件，而不是完全重建。但无论如何，这是一个有趣的问题。
是的，问题是它是由当前数据库结构生成的，无论数据库中的表是添加到父级还是您所在的分支中。这就是我所说的“重建” .我希望有人知道一种更好的方法，然后在每次使用迁移切换分支时从 master 删除/复制数据库:)
What is the preferred way to manage schema.rb in git?的可能重复

标签： ruby-on-rails rails-migrations schema.rb

【解决方案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

【讨论】：

【解决方案2】：

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

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

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

【讨论】：

这是正确的，但是在合并分支 B 之前，您不希望分支 B（执行迁移的地方）的表出现在 master 中。例如：如果有一个表用于分支 A 和分支 B，branch B 将 name 更改为 last_name，branch A 将首字母更改为 first_name。你合并分支 A，你不合并分支 B，因为它有一些复杂性 => 生成的模式包含 first_name 和 last_name，而你宁愿拥有 first_name 和 name。一些逻辑可能很好地检查不在 master 中的迁移并在 schema.rb 中回滚它们
一开始听起来不错，但有些迁移可能不那么可逆。您可以通过以下方式手动完成此操作： rake db:migrate VERSION=123 其中 123 是 schema.rb 中的迁移编号。这应该根据需要向前或向后迁移以到达该版本。最终，您最好的选择是尽早将每个分支的迁移合并到 master 中，即使您必须通过挑选来做到这一点。
我知道这一点，但问题是与大约 20 个分支一起工作，这些分支的生命周期都在几个小时到几个月之间。这就是复杂的地方：你忘记了分支有迁移，你搞砸了！除此之外，大表（100.000+ 条记录）上的迁移需要很长时间。如果当前分支中未使用该表，您宁愿将它们留在那里进行开发并仅更新架构。

【解决方案3】：

新鲜的临时数据库作为一种快速的解决方法

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

git checkout -- db/schema.rb
切换到不同的开发数据库，即更新config/database.yml
rake db:drop && rake db:setup
rake db:迁移
提交你漂亮的 db/schema.rb
还原 config/database.yaml 中的更改

【讨论】：