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

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

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

導入に際しgては、このかたの記事がとてもわかりやすく、勉強させていただきました。
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. まとめ:コンセプトの理解と、それに合わせた活用法を見出す必要あり

結論としては、「cloneやpullを高速化する」がメインの目的ならば、GitLFSは適していません でした。

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


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

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

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

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

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

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

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

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

Githubの転送量の上限

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

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

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

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

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

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


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

$ brew install git-lfs

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

$ git lfs install

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

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

$ 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でビルドしたファイルに、画像の実態がなかったのだから、表示されるわけがないですね。

【GithubPages VS Netlify VS Firebase】爆速で静的サイトのホスティングができるのはどれ?
Firebaseが速くておどろいた!静的サイトをホスティングするサービスを、ためしに幾つか使用してみて、メリットとデメリットを比較・検討しました。...

当然ローカルでも起こってました

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

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

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

CircleCIにGitLFSから画像をPULLさせる


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へ画像本体が送られることになりました。
無事に、サイトの画像も見れるようになります。

CircleCIを導入してシンプルなワークフローを実現!デプロイの効率化にチャレンジ
シンプルな直列のワークフローを実現して効率化を測る!素人でもできるCircleCIの活用法...

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

#circleci
#firebase
#git
ChaosBoy

テーマは「脱・思考停止」。
コメントはtwitterでお気軽に。