Contents — 7 sections
RicochetTanksで公開側と開発側を分けようとして、branchを切り替えた。
その直後、Gitを見ると大量の変更。
1714ファイル。
一瞬、何か大きく壊したと思った。
でも中身を追うと、ゲームロジックを1714ファイル書き換えたわけではなかった。
原因は、Gitの改行コード自動変換だった。
中身は同じなのに「変更あり」
Unity Projectでは、SceneやPrefab、設定ファイルなど大量のText Assetを持つ。
Git側の自動改行変換が入ると、内容上は同じでもbyte列としては差分になる。
今回も、branch切替をきっかけに大量のファイルが改行差分として変更扱いになった。
問題は単に git status が汚れることだけではなかった。
検査側から見ると、
「Sceneが変わった」
ように見える。
つまり、本当の実装変更と環境由来の差分が混ざる。
1714件の差分をそのまま進めなかった
こういうとき、怖いのは「たぶん改行だろう」と決めつけて、そのままcommitすること。
もし本当に一部の実装差分が混ざっていたら、まとめて飲み込んでしまう。
今回は、差分の正体を確認して、
- このrepositoryだけGitの改行自動変換を止める
- main側を元の改行へ戻す
- dev側も元の改行へ戻す
- contentの変更がない状態へ戻す
という手順にした。
結果として、main / devともに実装内容は変えず、改行だけを元へ戻した。
branchを分けるだけでは作業環境は分離できない
今回の件もあり、対人戦の開発は別作業folderへ分けた。
C:\work\RicochetTanks
C:\work\RicochetTanks-devGit branchだけでなく、working tree自体を分ける。
Unity Projectでは、
- Library
- generated files
- line endings
- local settings
- untracked assets
- branch switch時の大量更新
のように、Source以外の状態も大きい。
branchを分けたからといって、作業環境まで完全に独立するわけではない。
「変更されたファイル数」は実装量ではない
1714ファイルが変わった。
数字だけ見ればかなり大きな変更に見える。
でも今回は、意味のあるcontent変更は0。
この違いは、AI Agentに作業させるときにも重要だった。
「1714 files changed」という事実だけを見て、
「大規模なScene変更が入った」
と解釈すると間違う。
見るべきなのは、
- file count
- line diff
- binary / text
- line ending
- semantic change
- generated change
のどれなのか。
Unityでは特にノイズが大きい
UnityはText serializationを使うAssetも多い。
だから、
- line ending
- GUID
- generated metadata
- serialization order
のような変化が大量diffになりやすい。
差分が多いほどレビューが強くなるわけではない。
むしろ、本当に見たい変更が埋もれる。
今回やったのは派手な修正ではなく、
差分を減らして、差分を信用できる状態へ戻すこと
だった。
いまの運用
現在は、
- main側
- 対人戦開発用dev側
を分け、dev用に C:\work\RicochetTanks-dev を使っている。
宣伝素材を作る仕組みもdev側へ入れてある。
対人戦開発はこの環境から進める。
VRChatへのuploadだけは別。
Unity操作、VRChatへのsign-in、権利確認を含むため、人間の確認が必要なgateとして残している。
いまの結論
今回の1714ファイルは、1714個の実装変更ではなかった。
Gitの改行自動変換が作ったノイズだった。
でも、このノイズを放置すると、
- 本当の変更が読めない
- 自動検査が誤反応する
- AI Agentが差分を誤解する
- branch間の比較が信用できない
という別の問題になる。
だから開発環境では、
「差分があること」より「その差分を信用できること」
の方が大事だった。
PicoTowaでは、こういうコードそのものではない開発事故も残していく。