由于使用rails + git进行迁移是一种痛苦的类型，因此出现了新的荆棘......
在我对我的prod DB造成任何伤害之前，以下情况是否会造成严重破坏？如果是这样，我该如何处理？
我在一个单独的分支（feature/long-term）中处理长期功能。此功能是对许多组件的彻底检查，需要一段时间才能完成。此功能具有新迁移，已迁移到localhost DB。
同时，我需要通过另一个分支（feature/quick-fix）修复/添加迁移到prod系统。这有一个日期晚于feature/long-term迁移的迁移文件。
quick-fix和long-term的迁移彼此无关，它们不会发生冲突并在单独的表上工作。它们的运行顺序并不重要。
如果我将feature/quick-fix合并到主人和db:migrate，并在几天/几周内合并feature/long-term，则迁移文件顺序将首先为long-term。
这会以某种方式影响数据库吗？ （prod DB很重要，所以我不想reset）
答案 0 :(得分：3)
您所描述的是一个非常常见的开发工作流程（特别是在拥有更多成员的团队中），它对您的生产数据库来说非常安全。
从版本2.1开始，Rails非常智能，可以保留所有正在运行的迁移的列表，而不仅仅是最新的迁移版本。此信息存储在名为schema_migrations的单独表中。
所以，如果你今天推送一个新的迁移，说20140527_quick_fix.rb，然后一个月后你推出一个新的（但有一个较旧的时间戳）一个20140101_long_term_feature.rb，Rails仍然会知道后者从未在您的生产环境中运行，因此在rake db:migrate期间它会像您期望的那样处理它。当然Rails会知道它已经被处理了，最新的胜利再次被运行。
Rails版本2.0及更早版本用于在使用迁移时创建名为schema_info的表。此表包含上次应用迁移时的架构版本。
从Rails 2.1开始，schema_info表（由（自动））替换为schema_migrations表，该表包含所有应用的迁移的版本号。
因此，现在可以添加编号低于当前架构版本的迁移文件：迁移时，将自动应用那些从未应用过的“交错”迁移，并且在迁移时，从不应用将跳过“交错”迁移。