我正在将一个分支合并到master中，并且每个分支都进行了迁移。你如何看待rails3迁移已经对数据库运行
我想通过将它们应用到生产备份（PostgreSQL）来看到合并迁移是如何工作的。
我的两个分支迁移创建一个表，第一个失败，因为表已经存在。
这很奇怪，因为主回购没有该迁移。
文件db/schema.rb将被忽略，因此它表明该表存在于开发数据库上的早期迁移。我删除它，并再次看到现有的表，所以它显示我已经在本地运行它对错误的数据库。
那么如何找到已经运行的迁移列表。耙：db：版本只显示最新的一个。
rake db:migrate:status
# up 20131010170722 Devise create users
# up 20131015094519 Create customers
# down 20131121061642 Remove fileds from quantitative parameter
rake db:version确实会向您显示正在运行的最新迁移。您可以或多或少地假设所有早期的迁移已经运行，但如果您想确保您正在查看的迁移已执行，则可以评估schema_migrations表的内容，该表将成功列出所有的时间戳执行迁移。
我强调成功，因为这可能是您的问题。如果在执行迁移过程中（例如，在创建表之后）迁移失败，迁移将不会在schema_migrations中列出，但它无法回滚。我解释说，之前（here），所以我现在无耻引用自己：
rake db:migrate会告诉你错误的打印错误线索，并说：“后来迁移取消”。看起来合乎逻辑的是，它会撤消这些变化并恢复到之前的状态，但那会很棘手，因为它并不总是知道以前的状态会是什么。考虑一个你也在处理数据的迁移。或者您在其中删除多个列的迁移。它将不得不作出假设（如果可以的话），这可能会给你带来更糟糕的结果。
看看你的数据库，我怀疑该表确实已经存在，但如果你看看在它创建的迁移，你也许可以找到为什么迁移本身失败后（创建表）。如果你不能，请分享，这样我们可以看看它。
git分支是为代码。但无论你在哪个分支，db都是一样的。
如果你在分支中运行迁移，你会看到master在db中的变化。这是正常的行为。
对于开发数据库，这很容易，只需运行rake db:reset，你会没事的。
我非常想知道为什么这个答案会保证我第一次在SO上倒下。如果我错了，我想从中吸取教训。 –