Bitbucket LFS：Gitの「肥満」を解消し、開発速度を極限まで加速させるための処方箋
Gitはソースコード管理の革命児だが、バイナリファイルを詰め込むと途端に「肥満」する。リポジトリをクローンするたびに数GBの履歴をダウンロードし、CI/CDパイプラインがタイムアウトで死ぬ……そんな経験はないだろうか？
今日は、Bitbucket上で大容量ファイルを扱う際の決定打、Git LFS (Large File Storage) を「単なるツール」から「武器」へと昇華させるための実践的ノウハウを伝授する。
—
1. なぜ「Git LFS」が必須なのか：Gitの構造的限界
Gitは本来、全履歴をローカルに持つ分散型アーキテクチャだ。ここに数MB〜数百MBのバイナリ（テクスチャ、動画、OSイメージ等）を放り込むと、`git gc`や`git clone`が悲鳴を上げ、リポジトリのサイズが指数関数的に膨れ上がる。
LFSの真髄は「ポインタ化」にある。
バイナリ自体は外部ストレージに退避させ、Git本体には「どのファイルがどこにあるか」を示す軽量なテキストファイル（ポインタ）だけを保存する。これにより、クローン時間は劇的に短縮され、開発者の生産性は維持される。
—
2. 現場で即戦力となるLFS構築術
実践：既存リポジトリへの「クリーンな」導入
既存リポジトリにいきなりLFSを導入すると、過去の全履歴が残ったままになり、リポジトリの肥大化は止まらない。以下の手順で「過去の負債」ごと焼き払うのが鉄則だ。
1. LFSをインストール
git lfs install
2. 対象ファイルを追跡（例：psdファイルを全て対象に）
git lfs track “.psd”
3. .gitattributes をコミット（これを忘れるとチーム全員が死ぬ）
git add .gitattributes
git commit -m “LFS導入：psdファイルを追跡対象に指定”
4. 【重要】過去の履歴からバイナリを削除して最適化
BFG Repo-Cleanerを使用するのが最も高速で安全
java -jar bfg.jar –strip-blobs-bigger-than 10M
チーム開発の鉄則：`.gitattributes` の共有化
`.gitattributes` はコードの一部だ。これをリポジトリのルートに置き、Git管理下に入れておくことで、チームメンバー全員が同じルールでLFSを使うことを強制できる。
推奨する `.gitattributes` の構成例:
バイナリファイルをLFSで管理する設定
.psd filter=lfs diff=lfs merge=lfs -text
.mp4 filter=lfs diff=lfs merge=lfs -text
.unitypackage filter=lfs diff=lfs merge=lfs -text
重要な設定：テキストファイルはLF改行で統一する（クロスプラットフォーム対策）
.js text eol=lf
.sh text eol=lf
—
3. Bitbucket × LFSの生産性を最大化する「テックリードの極意」
① 「LFSロック」を使いこなせ
LFSの最大の弱点は「バイナリの競合」だ。psdファイルや動画はマージできない。
BitbucketのLFSロック機能を活用し、編集前にロックをかけるワークフローを構築せよ。
ファイルをロックして排他制御
git lfs lock assets/main_character.psd
作業完了後にアンロック
git lfs unlock assets/main_character.psd
これをCI/CDのフックやGitエイリアスと組み合わせれば、事故は撲滅できる。
② パイプライン最適化：CIでのLFSフェッチ
Bitbucket PipelinesでLFSを扱う際、デフォルトでは全てのファイルが落ちてくることがある。必要なファイルだけをフェッチして時間を節約せよ。
bitbucket-pipelines.yml
pipelines:
default:
- step:
script:
# LFSの追跡対象のみをフェッチ（–includeで範囲指定）
- git lfs fetch –include=”.psd”
- git lfs checkout
③ 神プラグイン・ツール
- [git-filter-repo](https://github.com/newren/git-filter-repo): BFGに代わる、より強力なリポジトリ再構築ツール。履歴を完全に書き換えたいならこれ一択。
- [GitKraken](https://www.gitkraken.com/): LFSのロック状態がGUIで一目瞭然。GUI派のメンバーが多いなら、このツールを導入するだけでLFSの運用ミスが激減する。
—
4. 最後に：テックリードからの提言
「とりあえずLFSを入れる」だけでは、いずれストレージ制限（BitbucketのLFSストレージ容量）にぶち当たる。
1. 除外の徹底: 不要な生成物（バイナリのキャッシュなど）は `.gitignore` で徹底的に排除する。
2. LFS pruneの習慣: ローカルの古いLFSファイルは肥大化の温床だ。`git lfs prune` を定期的に実行する運用をチームに定着させろ。
3. 可視化: 誰がどの巨大ファイルをコミットしたか、CIでログを吐き出し、閾値を超えたらSlackに通知を飛ばせ。
「技術とは、ツールを導入することではなく、ツールの副作用をコントロールすることである。」
BitbucketのLFSを使いこなせば、あなたのチームは「リポジトリが重い」という言い訳から解放され、本来の「価値創造」に集中できるはずだ。今すぐ設定ファイルを確認し、チームの生産性を最適化せよ。健闘を祈る。