编辑现有的Rails移植是一个好主意吗？(Editing Existing Rails Migrat

当开始了一个新的项目，也有很多，我觉得很容易地编辑现有的迁移和运行模式改变的db:clean或db:reset不是创建新的迁移。 当我这样做应用也打不生产，这意味着无后顾之忧，我可以重置/干净的数据库和我个人或小团队的一部分工作。

但是今天，我碰到下面的建议来到Rails的指南称其不是一个好主意：不鼓励编辑现有的迁移：

编辑现有迁移是不是一个好主意：您将创建为你和你的同事额外的工作，如果迁移的现有版本已经在生产机器上运行造成大麻烦。 相反，你应该写执行所需的修改新的迁移。 编辑还未被提交到源代码控制新鲜产生的迁移（或更一般地，尚未传播超出你的开发机）是相对无害的。

我想知道：

• 有什么潜在的陷阱我会遇到？
• 难道那些陷阱适用于我的情况（发育阶段，个人工作）？

Answer 1:

如果你是一个团队工作，你犯下的迁移则没有。

如果它只是在你的本地环境，然后只需要创建一个新的迁移固定你所需要的。 您可以删除表\列和你所需要的。

既然你清理数据库，并重新设置它，那么每个人都会做同样的或如果他们试图迁移他们将有问题。

Answer 2:

我工作的发展模式下的web应用程序。 虽然我单独工作，最好的做法是使用迁移修改数据库。 它可能会留下修改的痕迹，但你可以看到你的数据库结构的演变。 从长远来看，你将成为解决与移民分贝问题更快。

Answer 3:

数据库迁移是一种工具。 如同任何工具箱中最重要的是要明白什么是好，如何使用它，以及为什么使用这种方式。

• 直播现场：在直播网站，你不能简单地用耙子：DB复位，因为显然你需要的所有数据
• 在合作：你需要保持与其他开发商的一致性迁移。 如果他们已将数据输入他们的数据库（不管出于什么目的），并在代码中简单混合。 你现在已经完全foobared他们的努力，他们将被迫重新设置他们的整个数据库
• 耙分贝：回滚：一旦你修改，你必须重新设置代码，现在你不能回退运行。
• 这是一个坏习惯：在大多数情况下，礼貌的方式在做，这是创建一个新的迁移。 这是更好地在习惯和思维方式，以便能够快速，高效地创建新的迁移。

我没有真正告诉你不要做这件事。 这些只是大点，以我看到它为什么不这样做。 我大多数情况下，如果你是独自一人，或特别是如果你只是形成了您的项目（但可能不会立即意识到自己多么希望数据库看/工作与他们玩耍直接可能是最有效的。要了解为什么它是重要的在你面前何故的去瞎对最佳实践。

文章来源: Editing Existing Rails Migrations is a good idea?