こんにちは、冨田です。
2024年のF1シーズンが開幕し、今年もレッドブルが一強になるのかどうか、楽しみにしているところです。
先日、MigrationファイルのコンフリクトをGitHub上で修正しようとしたら、CIに怒られてしまいました。
原因を調べていく中で、GitHubとRailsのMigration及びschema.rbについて勉強することができたので、ブロクにしました。
概要
dev1
ブランチ(commit-4)でafter
オプションを使って新しいカラムを特定の位置に追加するMigrationファイルを作成- Migrationファイル
add_column :posts, :content, :text, after: :title, comment: '内容'
schema.rb
t.string "title", null: false t.string "content", comment: "内容" # dev1ブランチ commit-4 t.datetime "created_at", null: false t.datetime "updated_at", null: false
- Migrationファイル
dev1
ブランチ(commit-4)から派生した後続ブランチ(dev2
, etc)で開発を進めていました。- 後に
after
オプションが特定のデータベース環境でサポートされていないことがわかり、dev1
ブランチに新たなコミット(commit-7)を追加し、Migrationファイルとschema.rb
を以下のように修正しました。なお、この変更は後続ブランチには反映していませんでした。- Migrationファイル
add_column :posts, :content, :text, comment: '内容'
schema.rb
t.string "title", null: false t.datetime "created_at", null: false t.datetime "updated_at", null: false t.string "content", comment: "内容" # dev1ブランチ commit-7
- Migrationファイル
- featureブランチへのマージ過程で、Migrationファイルのコンフリクトが発生。
- 見逃しポイント:
schema.rb
の修正はコンフリクトが発生しておらず、見逃していた。
- 見逃しポイント:
- GitHub上でこのMigrationファイルの修正。
- その後、CIの実行中に
you can't define an already defined column
のエラーが発生しました。
結果
schema.rbに重複したカラムが生成されてしまっていました。
t.string "title", null: false
t.string "content", comment: "内容" # dev1ブランチ commit-4
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.string "content", comment: "内容" # dev1ブランチ commit-7
原因
GitHubでMigrationファイルを修正した際、ローカル環境でschema.rb
ファイルを更新しなかったため、dev1
ブランチのschema.rb
は修正後の状態になっていましたが、dev2
ブランチ以降は修正前の状態を維持していました。GitHubの履歴は同じ場所の変更でないため、schema.rb
はコンフリクトの対象にならず、結果としてdev1
とdev2
ブランチのschema.rb
の変更が両方とも反映されてしまいました。
[dev1ブランチ]schema.rb
t.string "title", null: false, "タイトル"
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
t.string "content", comment: "内容" # dev1ブランチ commit-7
[dev2ブランチ]schema.rb
t.string "title", null: false, "タイトル"
t.string "content", comment: "内容" # dev1ブランチ commit-4
t.datetime "created_at", null: false
t.datetime "updated_at", null: false
まとめ
Migrationファイルに関わる変更は、ローカル環境で必ず確認することをおすすめします。それは、schema.rb
の修正・変更にも関わってくるからです。
今回の失敗から、GitHubとRailsのMigration及びschema.rbについて理解を深めることができました。
最後までお付き合いいただき、ありがとうございました。また、新たな学びがあれば、ぜひ共有したいと思います!