2016-04-13 5 views
6

私のRailsアプリでgitで働いていて、2つのブランチがあり、それぞれに独自の移行があります。ActiveRecordの移行が外れている

1)branch001branch002は明らか2マイグレーションのタイムスタンプが最初後を作成した

マイグレーション20160101000001_create_table_B介しtableBと呼ばれるテーブルを作成)

2マイグレーション20160101000000_create_table_A介しtableAと呼ばれるテーブルを作成します。

でも、最初に準備が整ったので、branch002masterにマージするとします。私のスキーマファイルになり -

ActiveRecord::Schema.define(version: 20160101000001) do 
    .... 
end 

スキーマのバージョンは、それがすでに私の最初の分岐より高いレベル/バージョンにパッチだのActiveRecordを伝えます。

私が最終的に私の最初のブランチをマージするときに何が起こるでしょうか?

  1. スキーマのバージョンが20160101000000に回帰しますか?
  2. 最初のブランチのマイグレーションを実行しているときにスキーマが既に「パッチされている」とスキップしているので、それは何か問題はありますか?
  3. 一般的に、このような場合のベストプラクティスは何ですか?新しい、より新しいタイムスタンプで最初のブランチの名前を変更する必要がありますか?

ありがとう!本当に私はmasterに第二のブランチをマージするとき、マージの競合を解決するために何をすべきか迷っ

-

EDIT。私はそれを後のタイムスタンプとして残すか、それとも早いタイムスタンプに戻すべきですか?

<<<<<<< HEAD (master) 
ActiveRecord::Schema.define(version: 20160101000001) do 
======= 
ActiveRecord::Schema.define(version: 20160101000000) do 
>>>>>>> 282cda7... Adding Table B 

答えて

10

矛盾する場合は、2つのうち大きい方を選択してください。しかし、あなたが何を選んでも、実際の移行には何の影響もありません。

を次に実行すると、低い番号を選択した場合、この番号が(高いものに)変更され、schema.rbに変更があり、移行されません。それは問題ではない - あなたのコミットだけがちょっと変わってくるだろう。

rakeタスクは、見つかったすべてのマイグレーションを実行し、値はschema_migrationsテーブルにありません。そして、最も高い移行タイムスタンプをとり、このタイムスタンプをschema.rbに入れます。全体の移行のアイデアは、「最新のタイムスタンプ」(スキーマバージョン)に基づいていませんが、すでに実行されているすべての移行タイムスタンプを含むschema_migrationsテーブルの内容に基づいています。したがって、この表によって、移行はスキップされないことが保証されます。

2

非常に短いバージョンでは、移行が互いに干渉しないと仮定すると(たとえばテーブルを削除してもテーブルが削除されるなど)、問題に陥ることはありません。

スキーマファイルにはバージョン番号が1つありますが、移行を実行すると、レールファイルはschema_migrationsテーブルの内容と比較され、まだ実行されていない移行が実行されます既に実行されている最近の移行。

スキーマが矛盾する限り、私は個人的には移行を実行するだけで、schema.rbを再生成します。

関連する問題