branchを分けても足りなかった。Unity開発では作業フォルダごと分離した

Gitにはbranchがある。

main。

dev。

それなら開発環境も十分に分離できると思いやすい。

RicochetTanksでは、途中から作業フォルダ自体も分けた。

理由の一つは、branch切替で1714 filesが変更扱いになった改行事故だった。

branchは履歴を分ける。でも作業環境は共有する

通常のbranch switchでは、同じWorking Treeを書き換える。

Unity Projectではその周辺に、

• Library
• Generated files
• local settings
• untracked assets
• imported state
• line ending

のようなSource以外の状態もある。

Gitのbranchだけ切り替えても、これら全部が「別環境」になるわけではない。

大量差分が出て、切替そのものが怖くなった

公開側と開発側を切り替えたとき、Gitの改行自動変換で1714 filesが変更扱いになった。

実装内容は変わっていない。

でも差分は大量。

検査から見るとSceneが変わったようにも見える。

このrepositoryでは自動改行変換を止め、両branchを元の改行へ戻した。

そのうえで、対人戦の開発は別のWorking Directoryへ分離した。

安定側を触らずに開発できる

物理的に作業場所を分けると、

• 安定側を開いたままにできる
• dev側だけUnityを再importできる
• branch switchを減らせる
• untrackedな作業物を混ぜにくい
• 比較しやすい

という利点がある。

特にUnityはProjectを開くだけでもLibraryやImport状態を持つ。

CodeだけのRepositoryより、Working Directory分離の意味が大きい。

これはGit機能の優劣の話ではない

branchだけではダメ、という話ではない。

小さなRepositoryならbranch switchだけで十分。

今回の判断は、

Unity Project + 生成物 + 検査 + 宣伝素材 + 並行開発

という状況での運用上の選択。

重要なのは、Source Controlの構造と、実際に作業する環境の構造を同一視しないこと。

分けたから効果が証明されたわけではない

この運用は始めたばかり。

長期的に、

• 事故が減るか
• Disk消費が問題になるか
• Import時間がどう変わるか
• main/dev間の同期が面倒にならないか

はこれから観測する。

現時点で言えるのは、

branch切替で起きた環境ノイズを減らすため、作業場所も分けた

というところまで。

いまの結論

Git branchはCode historyを分ける。

でもUnity開発では、それだけで作業環境全体が分離されるわけではない。

RicochetTanksでは、

安定側と開発側をWorking Directoryごと分ける

運用へ移した。

効果はこれから測る。

ただ、少なくとも「切り替えるたびに1714 filesを見る」状態よりは、切り分けしやすい。