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