このタグの記事
Github
Railsマイグレーションの管理：schema.rbのコンフリクトを避けよう
こんにちは、冨田です。 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 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 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について理解を深めることができました。 最後までお付き合いいただき、ありがとうございました。また、新たな学びがあれば、ぜひ共有したいと思います!