编辑现有的Rails迁移是个好主意？
在开始一个新项目时，模型中有很多变化，我发现很容易编辑现有的迁移并运行db:clean或db:reset不是创建新的迁移。 当app没有达到生产时我就这样做了，这意味着我可以重置/清理数据库而不用担心，我正在独自工作或者是一个小团队的一部分。
但是今天，我在Rails指南中提到了以下建议，说它不是一个好主意并且不鼓励编辑现有的迁移：
编辑现有迁移并不是一个好主意：如果已在生产计算机上运行现有版本的迁移，您将为自己和同事创建额外的工作并导致严重的麻烦。 相反，您应该编写一个新的迁移来执行您需要的更改。 编辑尚未提交到源代码控制的新生成的迁移（或者更常见的是，尚未在开发计算机之外传播的迁移）相对无害。
我想知道：
- 我可能遇到什么潜在的陷阱？
- 这些陷阱是否适用于我的案例（开发阶段，独奏工作）？
如果您正在与团队合作并且您已提交迁移，则为NO。
如果它只在您的本地环境中，那么只需创建一个新的迁移，修复您需要的内容。 您可以删除表\列并执行所需操作。
由于您清理数据库并重置它，因此每个人都会这样做，否则如果他们尝试迁移就会出现问题。
我正在开发模式下的Web应用程序。 虽然我独自工作，但最佳做法是使用迁移来修改数据库。 它可能会留下一些修改，但您可以看到数据库结构的演变。 从长远来看，您将更快地解决迁移的数据库问题。
数据库迁移是一种工具。 像任何工具箱一样，最重要的是要了解它有什么用处，如何使用它，以及为什么要这样使用它。
- 实时网站：在实际网站中，您不能简单地使用rake：db reset，因为显然您需要所有数据
- 协作：您需要与其他开发人员保持一致的迁移。 如果他们已经将数据输入他们的数据库（出于任何目的）并且只是混合在您的代码中，该怎么办 你现在已经完全放弃了他们的努力，他们将被迫重置他们的整个数据库
- Rake db：rollback：一旦你修改了代码就必须重置，现在你无法运行回滚。
- 这是一个坏习惯：在大多数情况下，这样做的礼貌方式是创建一个新的迁移。 最好是养成习惯和心态，以便能够快速有效地创建新的迁移。
我实际上并没有告诉你不要这样做。 这些只是我为什么不这样做的主要观点。 在大多数情况下，如果你是独自一人，或者特别是如果你刚刚组建你的项目（并且可能没有立即意识到你希望数据库看起来/工作直接与他们一起玩可能是最有效的。重要的是要理解为什么因此，在你反对最佳实践之前。