As I understand it the point of migrations is so you can revert the database back to a known state during the last stages of development.
Right now I'm still "fleshing" out my first Rails app and I'm wondering if its ok to roll up my migrations into bigger ones rather than dozens of changes.
迁移的重点是您基本上拥有数据库更改日志，因此其他开发人员可以知道已进行了哪些更改，或者确保您的生产环境获得与您在开发期间所做的相同的更改。
至于你的问题：当然。如果您创建了一个新模型，然后在几分钟后决定“此列可能只是一个字符串而不是文本”，则回滚您的迁移，并更改该列，然后再次迁移。无需创建新的迁移。
除非您已经将之前的迁移提交到其他开发人员可能已获取的源代码管理，或者您已经在生产服务器上应用了迁移。然后你应该使用新的迁移。
作为 rspeicher 的附录，我将约束限制为迁移是否已发布，而不是它是否可供其他开发人员使用。如果它仍然是预发布版本，则可以通过使用正在使用的 SCM 的 post-fetch 挂钩，通知开发团队任何需要为主代码存储库的任何更新运行迁移。任何配置管理更改都是如此，而不仅仅是迁移。例如，更改初始化文件夹中某些内容的实现可能对开发模式下正在运行的脚本/服务器实例没有影响。对于大多数技术中的大多数团队以及一些持续集成的配置来说，这最终是一种必要的机制。或者，