7/7 本日の学び
■今日進んだこと
・DBをmasterブランチへマージ
今回受けた指摘一覧
・dependentオプションを使おう
親子関係のあるテーブルで、親のデータを削除したときに、子のデータが残ったままだと、整合性が取れずにエラーが出る。親のテーブルにdependentオプションを書くことで、自動で子のテーブルが削除されるように設定する。
対象となる子の特徴：親の外部キーにforeign_key:trueと書いていて、アソシエーションがbelongs_toの関係にあるもの。
例）親：productsテーブル 子：images,likes,commentsテーブル
このような子は親のデータが消えると、外部キーの参照元が消えるためどうしたらいいか分からなくなりエラーが出る。
なので、親のデータを消したら、同時に関連する子のデータも消えるように設定する。
■躓いているところ
コンフリクトを起こしてしまったようです。
明日、メンターさんにチャットで質問します。
ーーーーーーーーーーーーーーーー
明日、メンターさんに質問しようと思います。
コンフリクトを起こしているようです。
その画像↓
https://gyazo.com/dcd038af6719fad27bd1691e27ad26b6
カリキュラムで習ったコンフリクとの表記は<<<<<<< HEADと>>>>>>> masterという記述が、=======で区切られて追記されていました。今回私が見たものは表記が異なります。
■発生までの経緯
①issue13のブランチを切ってクレジットカード実装に必要なgem payjpを導入
②その後、テーブルの修正が整ったので、コードレビューをしようと思いブランチをissue11（DB専用のブランチ）に切り替えて、修正したいファイルのみ選択してコミット、プッシュ
③LGTMをもらったのでmasterブランチにマージ
④その後GitHub Desktopに戻ってリモートの差分をプルするのを忘れたまま（これが原因？）ブランチをissue13に切り替えて、テーブルを作成しようとした。
⑤その前に何となくgem fileを見たら添付画像のようになっていた
■解決策は手動マージ？
参考サイト
https://weblike-curtaincall.ssl-lolipop.jp/blog/?p=1464
https://chulip.org/entry/20120831/1346381439>>>>>>> Stashed changes
で囲まれている内容がどうもコンフリクトが発生している箇所のよう。git checkout コマンドで、コンフリクト発生箇所をマージしてあげると解決するそうですが、恐ろしいので、メンターさんに明日チャットで質問しようと思います。
これのせいで誰かに多大な迷惑かけていることになってないか、そっちが心配です。大丈夫かな・・・
ーーーーーーーーーーーーーーーーーーー
