项目数据库分多个版本：

dev 用于开发环境

lab 用于外网测试环境

release 用于外网正式生产环境

因为开发的需要会对数据库进行表结构的修改 (例如：加表，删表，添加表字段，重命名表名名，重命名表字段名) ,于时很自然的就想到 Migration 机制 .

在实际运行的过程中会遇到如下的情况：

1: dev 的数据库结构发生变化后，此时需要更新到lab测试环境中。但要求不影响现有的release版本. 于是新建一个 migration 文件，需要把表table1中的字段filed1重命名为filed2.此文件的命名类似 201405060512_xxxx.rb. 执行此 migration 并让其在 lab 版本的数据库中生效，到此lab的数据库结构已经更新到最新版本并可交由外网测试。

2: 这个时候release 版本发现一个重大 bug，需要把表table1中的filed1的值设置成一固定值300.这个必须 fix 它。于是开发人员都切到 release 版本中进行修改。最后生成一个 migrate 文件类似201405080512_xxxx.rb用于对release版本的数据库进行升级。但是这个时候并不需要升级lab版本的数据库。

3:最后到了一个开发周期，需要发布一个全新版本到外网测试。这个时候的流程大概会是这样的：

1) 把release版本的修改合并到lab分支上。

2) 把lab分支合并到dev分支上。

3) 本地测试dev分支 直到 ok

4) dev 分支合并到 lab 分支并把lab发布到外网进行测试。

5) 执行数据库升级脚本 (Migration)

看似这一切都很通畅，但是这里面就会有一个问题。release 分支的 migrate 文件 201405080512_xxxx.rb 的生成时间后于 lab 分支的 migrate 文件 201405060512_xxxx.rb 一天。在合并分支的时候虽然没有冲突，但是在下一次执行顺序上就会出现问题，回到刚在的 bug 中：

release 后于lab 如果按 Migration 的机制会先执行 lab 分支建的 migration 文件即是：将table1中的filed1重新命名为filed2

然后执行release分支的 Migration 即是：将table1中的filed1的数值设置成固定的数300

问题就在当执行release分支的时候找不到table1中的filed1字段，因为被前一个 migration 给修改成了filed2 程序抛出一个异常。

当然以上情况可以手动人为解决冲突，并可保证其运行。但是总感觉还有比较好的方案来处理这种情况.google 后一时又找不到好的解决方案。于是准备向ruby-china 求助。

上面的问题只是部分想到的冲突的情况，估计还会有很多类似或者其它冲突. 所以希望各位大牛们能出点主意。或者有什么比较好的处理类似情况的方案。