バックエンドはね、そんなに難しくないんですよ
さいきんのフロントエンドリファクタリングで発生するコンフリクトがすごくストレスフル
わんせた@12時以降起床部(@ars42525@odakyu.app)の投稿 For those who wants information about Yuito, subscribe my English posts only (available on account profile, Mastodon v4 or above).
くだらないこと言ってる人格は わんせた 、コード書いてる人格は kyori
呼ぶときは わせたん でもよし。たんってついてればかわいいので
Manages: https://odakyu.app https://nitiasa.com
Maintains: https://accelf.net/yuito (fork of Tusky)
when these instances down see here: @ars42525 @ars42525
Server Status: https://graph.accelf.net
バックエンドはね、そんなに難しくないんですよ
さいきんのフロントエンドリファクタリングで発生するコンフリクトがすごくストレスフル
DBの引っ越しがしたい気持ちもあるし、一定時間止めてデータ書き出して再スタートしたっていい
正直既存の引用のデータが吹き飛んでもいいやくらいの気持ちがあるので、いざとなれば独自改造分のDB変更を全部巻き戻すつもりではいます(最近拡張部分のメンテが本当に無理、とくに引用の面倒が見きれない)
mergeにすると、不定期的に発生するコンフリクト発生時の対処法がマージコミットに隠蔽されてしまうので、「結局のところこの機能の差分ってなんだっけ」が後でわからなくなってしまうという問題があり
さっき書いてた、丼のカスタム部分のコミット管理って、どうすんのがいいんだろ。
うちはrebaseし続けているので、常にカスタム部分のコミットが頭の方にいるんだけど、これだとrebase するたびにおなじconflictの習性が発生し続けるからビミョく。
mergeにするとそれはなくなると思うけど、コミットは埋もれていくと思われるので、パット見で見えなくなるのはちょっと不安みがあるきがしなくもない