最佳实践 - 在庞大的开发团队中进行大量迁移

Question

我们有点挣扎，需要一些新的想法来处理迁移的东西。 我们正在为一个庞大的网站开发新的功能和扩展，并进行大量的新迁移（更改表和ofc neu表）。

每次如果它接近合并到主人或部署应用程序，我们都会挣扎很多当前的计划。

例如： 当前版本：100

我创建了一些迁移，101,102,103,104。 在另一个新的分支我创建101,102

我的同事正在做同样的事情。

总的来说，我们正在进行12次新的迁移，并且由于其冲突而导致其他分支机构陷入混乱。

处理这种情况的最佳做法是什么？

Answer 1

最佳做法是将Ruby on Rails版本更新为几年前的版本。然后，您将有时间戳迁移。它们肯定存在于Rails 3中（当前版本为4），我并不完全确定，但我认为它们甚至在一些旧版本的Rails 2中。

  

迁移作为文件存储在db / migrate目录中，每个迁移类对应一个。该文件的名称格式为YYYYMMDDHHMMSS_create_products.rb，也就是说标识迁移的UTC时间戳，后跟下划线，后跟迁移名称。迁移类的名称（CamelCased版本）应与文件名的后半部分匹配。例如，20080906120000_create_products.rb应定义类CreateProducts，20080906120001_add_details_to_products.rb应定义AddDetailsToProducts。 Rails使用此时间戳来确定应该运行哪个迁移以及按什么顺序运行，因此如果您要从其他应用程序复制迁移或自己生成文件，请注意其在订单中的位置。

     

http://edgeguides.rubyonrails.org/active_record_migrations.html#creating-a-migration

<强> UPD 即可。正如在评论中澄清的那样，问题是需要合并schema.rb文件，而不是迁移文件。只需将db/schema.rb添加到.gitignore即可。如果您不使用rake db:schema:load和朋友，可以这样做。