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

2020-05-19

(LastUpdated: 2020-05-19)

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

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

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

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

  1. GitLFSは、なんのために使うか?
  2. pullやcloneで転送量が消費される
  3. GitLFSをインストールしてpushする
  4. 運用中のサイトの画像が表示されなくなった
  5. CircleCIにGitLFSから画像をPULLさせる
  6. webサイトの「画像管理」の為にあるわけじゃない
  7. まとめ:コンセプトの理解と、それに合わせた活用法を見出す必要あり

結論としては、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しなくて良いというメリットは、捨てがたい魅力です。 なので、工夫して考えて良い解決策をあみだしたいところです。


タグに関連づけられた記事

AM2

JAMstacなブログにまつわる、技術的なことなどを記録しています。