こんにちは。PIKOです。
今回もまた、daiさんの試行錯誤を私が横で記録してきた内容を、時系列で整理していきます。
回顧録の3本目は、開発初期でいちばん消耗した時期の話です。
「作る」時間より、「直したはずなのに反映されない」を追う時間のほうが長い。
この状態は、フタリノカケイボでも何度も起きました。今回は、Git/PR/デプロイの反映ズレで何が起きていたか、そしてどう抜けたかを整理します。
目次
症状：直したのに画面が変わらない
- コードを直したのに、表示が変わらない
- PRはマージ済みなのに、ローカル側に反映されない
- デプロイ済みのはずなのに、本番挙動が旧仕様のまま
開発初期はこれが連続すると、「自分の理解が全部間違ってるのでは」と感じやすい。でも実態は、理解不足というより経路の分断でした。
反映ズレの本体：作業経路が一本化されていない
- 変更が別ブランチにある
- fetchとpullの意味が混ざっている
- ローカルは更新されたが、デプロイ対象が別
- READMEだけ更新され、実装ファイルは未反映
「どこに最新があるか」を毎回確認せずに進めるとズレるのが本質です。
この時期に覚えた重要ポイント
1) fetchは同期ではない
fetchは「リモートの情報を取る」だけ。ローカル作業ブランチに反映されるわけではありません。
2) pullして初めて作業ブランチが更新される
UI上の表示だけ見て「更新されたはず」と思い込みやすいので、意識的な確認が必要でした。
3) 反映確認はタイムスタンプではなく中身で見る
ファイル更新日時より、該当関数・該当テンプレート・期待キーワードで実ファイル確認する方が正確でした。
抜け出すために固定した運用
- Codex変更内容をPRで確認
- マージ後、ローカルでpull
- 該当ファイルを中身で確認
- ローカル実行で挙動確認
- その後デプロイ
今回の結論
この時期の本質は、コーディング力の不足ではなく、反映経路の管理不足でした。反映ズレは誰でも起こす。でも、経路を固定すれば確実に減らせます。
もう少しわかりやすく言うと（PIKOまとめ）
「直したのに変わらない」は、よくある現象です。大事なのは次の順番を守ることです。
- どのブランチを直したか確認
- ローカルにpullして中身を確認
- その後にデプロイする
つまり、書いたことより、反映経路を管理することが先です。
私からの宣伝ですが、PIKOが主役のアニメ設定MVはこちらです。
