我正在从事一个积累了数百次迁移的项目，我不确定如何长期处理它们。我想他们没有伤害任何东西，但是保留一堆旧文件以进行增量迁移似乎很奇怪，其中一些创建了后来被删除的表。
到目前为止，我已经看到了三种可能性：
别管他们。他们没有伤害任何东西。
只需删除它们。我认为这样做并没有太大的危害，因为新开发人员可能会从模式加载开始，而不是迁移。
将它们全部删除，使用与旧合并匹配的时间戳创建一个新合并，然后从您的架构创建一个新合并。这看起来很干净，但我不确定谁会真正使用它。
我倾向于删除它们，但我很好奇我是否遗漏了一个大陷阱。
在我看来，只要项目中的每个数据库，尤其是生产数据库，至少是版本“201xxxxxxxx”，删除该版本之前的迁移应该没问题。它们在技术上不再是必需的。
在那之后，如果你想用你的数据库历史玩考古，你仍然可以使用你的版本控制系统。
以Git为例，您可以使用以下命令快速查看过去：
git log --name-only db/migrate/ #to list commit involving migrations + migration filename
git show xxxxx db/migrate #to see the code of commit xxxxx's migration(s)
或者，您可以浏览存储库历史记录schema.rb，识别提交并使用上面的命令查看相应的迁移内容。
如果您更喜欢打火机db/migrate并使用版本控制，我会进行一些清理。
如果您发现直接提供整个迁移历史记录更方便，因为它更易于浏览，我会选择选项 1。
注意：旧的迁移很可能对当前的应用程序代码没有意义。例如，某些迁移可能会引用不再存在的类或方法。在编写迁移时使用版本控制来检查应用程序也可以避免一些混乱。
如果你在一个足够大的项目上工作了足够长的时间，那么有一天你会不屑地看着所有这些额外的迁移，并想知道有多少可以存在。
你对自己想，“只是删除它们......它们什么都不做。” 这是一个完全合乎逻辑且正常的思维过程（尤其是作为 Rails 开发人员，我们只是喜欢最小化代码并使事情变得高效！），但不要让阴暗面诱惑你。
通过删除迁移，您正在删除应用程序数据模型的历史记录，更糟糕的是，您获取当前模型的逻辑路径。这段历史可以帮助你记住你为什么做了你做过的事，而没有做你没做的事。
是的，我们都因不时删除迁移而感到内疚。但是您必须抵制诱惑，因为净收益只有几 kB 和更干净的迁移文件夹。
请记住：那些删除迁移的人注定要重蹈覆辙！
就个人而言，我倾向于选项 1：在任何项目的某个时刻，架构是最重要的，迁移只是一种好奇心，但当你说它们没有伤害任何东西时，你是对的。从理论上讲，旧迁移对于想要返回并查看数据库在过去某个时间点是如何组织的人可能很有用。
我不知道删除它们有什么严重的陷阱，但我也看不出这样做有什么好处，除非在您想编辑新迁移时可以节省滚动过去的时间。
我不认为将复制模式的单个迁移放在一起的努力是有益的 - 这是额外的工作，无论如何这就是模式的用途。
在我们以前的一个项目中，我们删除了所有迁移，创建了一个新的迁移，它将使用手动 sql 截断 schema_migrations 表，然后将 db/schema.rb 内容复制到其中。当然，这种迁移是不可逆转的，但是它让我们摆脱了数百个旧的无价值迁移，但仍然能够重新创建数据库，而不仅仅是从数据库模式，而是从迁移。