更新功能分支中的迁移时间戳
假设我的主分支 (devlop) 和功能分支都在积极开发。两者都时不时地添加迁移。在将功能分支合并到主分支之前，我将把它重新设置到主分支上。
因此，只有在最近的开发分支迁移之后进行所有功能分支迁移才有意义。
有没有一种方便/建议的方法来重命名这些文件？我可以生成虚拟迁移并重用为它们生成的时间戳 - 但我想知道是否有我不知道的最佳/常见实践？
Let's say there's active development in both my main branch (devlop) and my feature branch. Both are adding migrations now and again. Before merging the feature branch into the main branch, I'm going to rebase it onto the main branch.
So it only makes sense for all the feature branch migrations to come after the most recent develop branch migration.
Is there a handy/advised way to do the renaming of these files? I can just generate dummy migrations and reuse the timestamps generated for them -- but I wonder if there's a best/common practice out there that I don't know about?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我还没有找到可以为您执行此操作的 Rails 功能，但如果有一个
migration touch命令或其他命令就更好了。无论如何，我们这些天所做的只是生成一个新的迁移，复制时间戳并重命名旧的迁移。一般来说，迁移是独立的，顺序并不重要，但有时我们会遇到顺序依赖性，因此我们需要更新时间戳。I haven't found a rails feature to do this for you, but it would be nice to have a
migration touchcommand or something. At any rate, what we do these days is just generate a new migration, copy the timestamp and rename the old one. Generally migrations are stand alone enough that the order doesn't matter, but occasionally we run into order dependencies so we need to update the timestamps.正如您的问题的评论中提到的，无需更改文件名。
还提到，在其他迁移存在之前，通常不会发生依赖于其他迁移而写入迁移的情况。 （如果是这样，那么你没有做正确的事情）。所以这种需求不应该出现。
在极少数情况下，功能开发人员想要合并多个迁移（功能迁移之间存在主干迁移），他应该将这些迁移合并到新的（或最后一个）迁移中。无论如何，功能开发人员有责任确保满足依赖性。
这样做还可能会给其他开发人员带来一些恼人的副作用。由于 schema_migrations 中的时间戳不可用，相同的迁移将在其数据库上再次运行。
As mentioned in the comments on your question, there is no need to change the file names.
It was also mentioned that it won't usually happen that migration is written, depending on an other migration, before that other migration exists. (If it does, your not doing things right). So the need should not arise.
In a rare case where a feature developer would want to merge multiple migrations (where there is a trunk migration in between the feature migrations) (s)he should merge these into a new (or the last) migration. In any case, it's the feature developer's responsibility to make sure dependancies are met.
Doing so could also create some annoying side effects for other developers. The same migration would run again on their database as the timestamp in schema_migrations would not be available.