GitLFSは大容量のファイル用！webサイトの画像管理をしてみたけど意味なかった

2020-06-11

(LastUpdated: 2020-06-11)

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

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

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

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

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

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

GitLFSは、なんのために使うか？

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

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

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

大容量かつ必要な人が限られているファイルに有効

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

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

pullやcloneで転送量が消費される

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

Githubの転送量の上限

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

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

転送量のカウント = ダウンロード時

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

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

GitLFSをインストールしてpushする

ソファに深くかけてリラックスした男性がmacを操るすがたまず、brew でgit lfsをnstallします。 bash $ brew install git-lfs

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

Git LFSで管理するファイルを指定

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

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

git add , commit , push

すでに適用されているプロジェクトに追加したため、この設定で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にGitLFSから画像をPULLさせる

circleciのロゴ 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 git@github.com git-lfs-authenticate daisukenagai/homeostasis.git download
     git lfs pull

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

webサイトの「画像管理」の為にあるわけじゃない

暗闇の中で目がバツじるしの光るLED仮面をつけた青年そもそも「本来の画像を取得しないと、開発が進めずらい」という状況下で導入したのが、ダメでしたね。

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

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

メリットを享受できる方法

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

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

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

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

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

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

まとめ：コンセプトの理解と、それに合わせた活用法を見出す必要あり

octcatのステッカーが貼られたmacをあやつる人の画像 Git LFSのコンセプトは、「大容量のバイナリファイルのバージョン管理」です。これをちゃんと理解しておくべきでした。

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

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