「あれ？やたらとcloneに時間かかるな・・・」
新しいマシンを買って、このブログのデータをgithubからcloneにした時に思いの外時間がかかりました。

「あ、そういえば、Git LFSってあったよな」と思い立ち、気軽に導入してみました。

導入に際しては、この方の記事がとてもわかりやすかったです。
macOS で Git LFS (Large File Storage) を使ってみる - CUBE SUGAR CONTAINER
勉強させていただきました😃

基本的には、こちらの通りに進めていけば、スムーズに導入可能です。
僕の記事では、これに沿った導入〜結果を書いていきたいと思います。

結論としては、GitLFSを入れたからと言って、必ずしもcloneやpullが高速化する訳ではない ということです。

しかし、シーンによってはとても重宝するはずです。
導入前に、きちんとプロジェクトと合っているかを考えましょう。

PSDやAIに代表される「デカイサイズのファイルのバージョン管理ができる」というのがテーマとなっています。

あくまで、gitで扱いづらいファイルの、バージョン管理をするために導入するもの。

僕はここを勘違いしていて、「リポジトリの軽量化」的な発想で導入してしまったわけです。

Git LFSで有利なのは、PSDやAIなどの大容量のデータ。
大量のデータというわけではないのです。

また、その大容量ファイルが、常に開発者全員に必要なファイルだと、結局はpullをしなければいけなくなります。

GLFSの導入を予定しているということは、巨大なファイルを扱うということになると思いますが、githubの転送量の上限に注意する必要があります。

• 転送量が月間1GBまで
• 無料保存できるストレージの容量は1GBまで

場合によっては、課金が必要かもしれないですね。
転送量のみならず、ストレージ容量も多くないのは要チェックです。

カウントされる転送量は、ダウンロードの時のみを指しているとのこと、アップロードは含まれないようです。
よって、

• clone
• pull

これら動作時に、転送量を消費していきます。

まず、brew でgit lfsをnstallします。

$ brew install git-lfs

好みのプロジェクトでGit lfsを使えるように、プロジェクトにインストールします。

$ git lfs install

ファイル単位で登録することもできるし、特定の拡張子を登録ということでもOK。
僕の場合は、画像類全般なので、拡張子ごと登録してみました。

$ git lfs track *.jpg

これをすることで、プロジェクトに.gitattributesという設定ファイルが作成されます。

すでに適用されているプロジェクトに追加したため、この設定でgit statusでjpgが一気にリストされました。

これをいつも通り、git add して、git commit -m "Git LFSを使ってみた！" 。
Pushもいつもどおりgit push 。

ファイルの動きは以下のような感じになります。
- 画像以外のファイル -> 今まで通り
- 画像本体 -> git lfs用のストレージに保管
- 画像のポインタ -> 画像以外のファイルとともに、リモートリポジトリへ。

気になるところ
例えば、リーダーがGitLFSをインストールして設定してmergeしたとする。
では、インストールしていないメンバーが、トラッキング設定されたファイルをpushしたらどうなるのだろうか？
答え
普通に、リポジトリへ画像の本体がプッシュされるらしい

公開しているサイト（このブログです）の画像が、軒並みなくなりました。
「firebaseに画像が上がってないのか？」と思ったらfirebaseの問題ではありませんでした。

きちんと平常運転。

画像の代わりに、画像のポインタが上がっていた というわけです。

CircleCIでビルドしたファイルに、画像の実態がなかったのだから、表示されるわけがないですね。

後で気づいたんですが、移行後のローカルでのテストで、すでに見えなくなっていました😅
環境移行前のマシンには、画像は全てローカルにある状態。
なので、画像ポインタのことは、完全に意識から消えてました。

本来の画像は、Git lfsサーバーからpullしてくる必要があります。
git lfs pull
これだけでOK。

ん、あれ？・・・これ、意味なくね？

circleCIがビルドする時に、画像本体のファイルがないといけない。
なので、circleCI上でも、Git LFSから

git lfs pull

してくる必要があります。

.circleci/config.ymlに以下のステップを追加します。

- run:    name: Git LFS (install Git Large File Storage)    command: |      curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | sudo bash
      sudo apt-get install git-lfs=2.2.0
      ssh [email protected] git-lfs-authenticate daisukenagai/homeostasis.git download
     git lfs pull

これにて、firebase hostingへ画像本体が送られることになりました。
無事に、サイトの画像も見れるようになります。

そもそも「本来の画像を取得しないと、開発が進めずらい」という状況下で導入したのが、ダメでしたね。

僕のケースでは、「毎回、git lfs pullが必要じゃん？」ってことで、気づきました。
「jpgなどの単なる画像データに適用するのはあまり意味をなさない」そんな気がしてきました。

大容量ファルのバージョン管理 というのが基本原則でしたね。

そんな環境下でも、使いようによってはメリットと言えそうなものもあります。

• リポジトリとは別のタイミングで、画像をpullできる
• 必要な画像だけを指定してpullできる
• pull、cloneが早くなる

やはり、pullやcloneを早くなるだけでも、捨てがたいメリットと言えます。

つまり、ここで考えるべきことは、そもそもの画像の管理法。
泥臭い例えですが、「古い画像はそれが古いとわかるディレクトリに入れておく」とか、そんな風にして管理をすることができれば、Git LFSの良さを享受できそうです。

しかしながら、これが徹底されていれば、そもそもGitLFSを適用するまでもなく解決しているのです。
不要なファイルをその都度削除すればいいのだから・・・

そもそも、「ちゃんと管理しとけよ」という話に帰結してしまう・・・😓

Git LFSのコンセプトは、「大容量のバイナリファイルのバージョン管理」です。
これをちゃんと理解しておくべきでした。

仕事で関わっているプロジェクトでも、データの肥大化が問題になっており、解決策の一つとして考えています。

不要なファイルをPullしなくて良いというメリットは、捨てがたい魅力です。
なので、工夫して考えて良い解決策をあみだしたいところです。