不，您不应该删除迁移，根据RubyonRails自己的建议，当您在已经存在迁移的旧项目上创建新数据库时，最好运行bin/rails db:schema:load
从 schema.rb 开始：
这个文件是Rails在运行bin/rails db:schema:load时用来定义模式的源文件。在创建新数据库时，bin/rails db:schema:load往往比从头开始运行所有迁移更快，并且可能更不容易出错。如果旧的迁移使用外部依赖项或应用程序代码，则这些迁移可能无法正确应用。

• 请注意，Ruby on Rails db:setup支持db:create、db:schema:load和db:seed，这在设置项目时很有用 *

一般情况下使用db：schema：load即可

通常最好的解决方案是运行bin/rails db:schema:load，正如@Mshka所说。
但是为了获得一些潜在的灵感，这里有一个案例研究，其中删除了一个旧的迁移文件（这是一个禁忌），我恢复了它，这样我就可以再次运行db:migrate...

案例分析：删除迁移恢复

在这个例子中，一个同事删除了一个旧的迁移，没有明显的原因（可能是意外），所以db:migrate不再在开发中的空数据库上工作。然而，在从旧提交中跟踪已删除的迁移文件之后，简单地重新添加该迁移文件会带来新的问题：迁移现在在生产中失败，因为迁移添加的列已经存在于生产中。在我的情况下，解决方案是修改旧的迁移

class AddContigFileidToSubmissions < ActiveRecord::Migration[4.2]
  def change
    add_column :submissions, :contig_fileid, :string
  end
end

到

class AddContigFileidToSubmissions < ActiveRecord::Migration[4.2]
  def self.up
    if !column_exists?(:submissions, :contig_fileid)
      add_column :submissions, :contig_fileid, :string
    end
  end

  def self.down
    remove_column :submissions, :contig_fileid
  end
end

这允许db:migrate在开发中再次在空数据库上工作（现在正确添加了该列），并且在部署到生产时迁移继续工作（Rails会发现该列已经存在于数据库中，并且不做任何更改）。
因此，如果您发现以前的提交错误地损坏了旧的迁移，那么修复损坏可能是一个方便的解决方案。但用你的判断力。