gitにおいてバイナリファイルは避けるべき

Prompt

Gitが差分を見つけることが難しい形式のファイル(.docxのようなファイル)を頻繁に変更すると、リポジトリの変更履歴は肥大化する？

その通り！Gitが差分を見つけることが難しい形式のファイル（.docx、画像ファイル、バイナリファイルなど）を頻繁に変更してコミットすると、Gitリポジトリの履歴は非常に速く、かつ非効率的に肥大化するよ！🚨

🔑 履歴が肥大化するメカニズム

Gitはテキストベースのファイル管理に最適化されています。ファイルの差分（diff）を見つけるのが難しいバイナリ形式のファイルを扱うと、Gitの効率的なデータ管理の仕組みが機能しなくなるんだ。

テキストファイルの場合: Gitは、ファイル間の差分（デルタ）だけを保存するデルタ圧縮という手法を使う。例えば、100行のファイルで1行だけ変更した場合、Gitは変更された1行の情報だけを効率的に格納できる。
バイナリファイル（.docxなど）の場合: .docxのようなファイルは、XMLやバイナリデータが複雑に圧縮された構造を持っている。人間がテキストとして見ると数文字の変更でも、ファイル全体で見るとバイナリの並びが大きく、かつ不規則に変わってしまうことが多い。
結果: Gitは効率的な差分を生成できず、ファイル全体を新しいオブジェクトとして保存するしかなくなる。

変更のたびに完全コピー: 1MBの.docxファイルを100回コミットで変更すると、Gitの内部データベース（オブジェクトストア）には1MBのファイルが100個（合計100MB）近く蓄積されることになる。
リポジトリの非効率化: これにより、リポジトリのクローン（Clone）やフェッチ（Fetch）のサイズが不必要に大きくなり、Git操作全体の速度が低下するんだ。

このような問題を回避するために、Gitでは**Git LFS（Large File Storage）**という拡張機能を使うのがベストプラクティスだよ。

仕組み: .docxなどの大きなファイルをGit本体に直接格納する代わりに、LFSはGitリポジトリにはそのファイルへの**小さなポインター（参照）**だけを保存する。実際の巨大なファイルは、外部の専用ストレージサーバー（GitHub LFS、AWS S3など）に格納される。
効果: リポジトリの履歴はポインターのサイズ分しか増えないため、Git操作は高速なまま保たれるよ！👍