LFS（Git Large File Storage）の概要説明します。
最近はGitHubも勉強しているため、自己啓発も兼ねて書いていきます。
- Git LFSの説明
- GitHubの場合（使い方や制限等）
以下、目次となります！
Git LFSとは？
最初にGit LFS（Git Large File Storage）について簡単に説明します。
- Gitは大容量ファイルの管理は不得意。
- Git内ではURL（ポインタ）だけ管理して、実体は別の場所に格納しよう。
え、これだけ？
はい。
管理が不得意という言葉に対する具体的な症例として、操作が重くなるというのが一番でしょうか。（Gitにおいて管理ができなくなるってわけじゃありません。）
けど、GitHub、Gitlab、Backlog等のGitホスティングサービスでは、Gitリポジトリに大容量ファイルを突っ込まれても困るのか、容量制限があります。
→ 1ファイル辺りの容量制限（100MB等）があるため、LFSを使わざるを得なかったり、大容量ファイルを諦めたり、大容量ファイルは別のサービス（DropboxやGoogleDriveなど）で管理って流れになります。
GitHubのLFSの場合
GitHubでLFSについて
公式サイトの関連記事はこの辺りでしょうか。
以下、LFSに関する数値関係です。
| プラン | 1ファイル辺りの容量制限 | 帯域 (無償) | ストレージ (無償) | LFS利用時の 最大ファイルサイズ |
|---|---|---|---|---|
| Github.com (Free) | 100MB以上はだめ。 | 10GB | 10GB | 2GB |
| Github.com (Team) | 100MB以上はだめ。 | 250GB | 250GB | 4GB |
| GitHub enterprise Cloud | 100MB以上はだめ。 | 250GB | 250GB | 5GB |
| GitHub enterprise Server | 特になし。 （設定値を設けることも可） | ー | ー | ？ |
◇ LFSはPrivate/Public無関係に同じ制限！
PublicだとActionsやSecurity関係が無償のことが多いですが、LFSは有償です！
◇ GitHubのLFS関係のエラー（参考）
GitHub Desktopを利用している場合、コミット段階で次の警告が表示されます。
警告を無視してコミット後にプッシュすると、アップロードが終わった段階でErrorが表示されます（すぐにErrorにならない）。
公式マニュアルによると、ファイル容量50MBを超えた段階で、GitHubから警告がくるとらしい（見たことないんだよなぁ）。
LFSストレージとは？
LFSを利用するファイルの格納場所（ストレージ）です。
従量課金は1GB辺り「$0.07/month」です。
例えば、
- 無償枠が「10GB」であれば、合計10GBのファイルが置けます。
- 1GBのファイルを10個格納したら、11個目から従量課金が発生します。
- 100GBの場合で$7（≒\1,050）。
LFS帯域とは？
LFSストレージからファイルをダウンロードした転送量のことです。
従量課金は1GB辺り「$0.0875/month」です。
つまり、
- LFSサーバ → 自分のPCへの転送時にLFS帯域を消費します。
- 無償枠が10GBとしたら、1GBファイルを10回ダウンロード（クローン）したら消費です。
- 100GBの場合で$8.75（≒\1,300）。
Publicだとやばいかな？
一般利用者のダウンロードですぐに消費かな。（EDosの的）
課金について
従来はデータパック（50GBでいくら）方式でしたが、従量課金になりました！
- 帯域（Bandwidth）：$0.0875
- ストレージ（Storage）：$0.07
単位はPrice per-GiB (USD)です。
従量課金のため月々の上限を設定することも可能です。
LFSのサーバは自前でも準備できる
自前で準備も出来るようです。
例えば、LFSサーバをAWSのS3とする場合ですね。
→ 詳しくはググると、先輩方の実施記事がいくつも見つかりました。
- Qお得なのかな？
- A
状況によりけりです。クローン先がS3と同じリージョンであればお得になるだろうけど、ローカルPCにクローン（インターネットアウト）が多いと割高ですね。
管理を気を付けないと、面倒＆高額になりそうです。
操作例
LFSをサポートしているGitホスティングサーバは結構ありますが、今回はGitHubを使いました。
全体的な流れ
- git lfs導入
- git lfs対象ファイル設定
- 後はいつも通り、commit＆pushすればOK
初期設定とプッシュまで
git lfsを導入していない場合は、別途導入しましょう。
Windowsであれば、以下からGitをデフォルトでインストールすれば入ります。
対象ファイルの設定は次の通り。
<リポジトリ内で初期設定>
$git lfs install
Updated Git hooks.
Git LFS initialized.
<LFSファイルを指定（Track）>
$git lfs track "*.exe"
Tracking "*.exe"
→ .gitattributesが生成されます。
<他の指定方法>
$git lfs track "/this.exe" ← 特定階層のファイル指定
$git lfs track "/bin/*" ← 特定フォルダの全ファイル指定
<LFSファイルの設定状況>
$git lfs track
Listing tracked patterns
*.exe (.gitattributes)
Listing excluded patterns
※または「.gitattributes」ファイルを直接確認しましょう。
<LFSファイルの指定解除(UnTrack)>
$ git lfs untrack "*.exe"
※または「.gitattributes」ファイルから該当行を削除しましょう。この段階で関連ファイルをコミット＆プッシュすれば準備完了です。
- git add <対象ファイル>
- git commit -m “message”
- git push
- Q容量指定でgit lfs trackは出来ないの？
- A
出来ないため、名前でtrackを指定してください。
かといっても”*.exe”のように指定してしまうと、軽量なexeファイルもLFS管理ファイルになるので、具体的な名前、パスで指定しましょう。
設定・状態の確認
<LFS trackの設定確認>
$git lfs track
Listing tracked patterns
*.exe (.gitattributes)
Listing excluded patterns
<LFSとして現在登録されているファイル（Add後に確認可）>
$git lfs ls-files
914ffc96ce * this.exe
7f5678212b * that.exe
<LFSの候補ファイル>
$git lfs status
On branch main
Objects to be pushed to origin/main:
Objects to be committed:
.gitattributes (Git: 7b2242b)
hoge/1.exe (LFS: 4c26c7d)
hoge/2.txt (Git: 4c26c7d)
readme (Git: 4c26c7d)
Objects not staged for commit:
ところでgit lfs ls-filesを利用した場合に、ファイル名の左横が「*」だったり「-」だったりすることがありますが、次の通りです。
- 914ffc96ce * this.exeの場合：実体がある
- 914ffc96ce – this.exeの場合：実体がない（ポインタファイル）
「-」（ポインタファイル）の場合は、後からgit lfs pullを実行すれば実体がダウンロードされます。
Cloneの挙動
GitやGitHub Desktopの場合、LFSファイルも自動的にダウンロードされました。
大容量のLFSファイルも使うのであれば良いのですが、不要な場合、LFS帯域の節約のためにダウンロードしたくありません。
次のようなコマンドを実行しておくと、LFSファイルはポインタしかダウンロードしません。
$ git lfs install --skip-smudge
Git LFS initialized.
$ git config -l
→ filter.lfs.smudge=git-lfs smudge --skip -- %f
があれば設定OK上記コマンドはリポジトリ内(.git)のフォルダじゃなくてOKです。
後から、ダウンロードしたい場合は、次のコマンドを実行します。
git lfs pull [ファイル名]
※ファイル名を指定してもしなくても全ファイルダウンロードかも。。また、やっぱり最初から全部ダウンロードする設定に戻したい場合は、次のコマンドを実行します。
$ git lfs install
Git LFS initialized.
$ git config -l
→ filter.lfs.smudge=git-lfs smudge -- %fGIT_LFS_SKIP_SMUDGE=1を付けてダウンロードします。
例：GIT_LFS_SKIP_SMUDGE=1 git clone https://@github.com/xxx.git
※先ほどのgit config設定だと、今後のclone全部が対象でしたが、上記であれば、ピンポイントで設定（適用）することが出来ます。
その他
GitHubで制限を超過
GitHubでLFS帯域やストレージの制限を超えるとエラーが表示されます。
batch response: This repository is over its data quota. Account responsible for LFS bandwidth should purchase more data packs to restore access.
Uploading LFS objects: 0% (0/1), 0 B | 0 B/s, done.
error: failed to push some refs to 'https://github.com/...git'
x509: certificate signed by unknown authority
LFSファイルのダウンロードフェーズで「x509: certificate signed by unknown authority」が表示されてダウンロード出来ないことがありました（企業内だと多い？）
セキュリティ的によろしくありませんが、暫定で
git config –global http.sslverify false
とすることで回避出来ます。
For security reasons, this is disallowed by default.
fatal: active `post-checkout` hook found during `git clone`:
C:/Users/xxx/.git/hooks/post-checkout
For security reasons, this is disallowed by default.
If this is intentional and the hook should actually be run, please
run the command again with `GIT_CLONE_PROTECTION_ACTIVE=false`
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry with 'git restore --source=HEAD :/'これのことかな。gitクライアントのバージョンによって生じる不具合です。
まとめ
Git LFSに関する簡単な説明及び、GitHubでのLFSに関してざっくりとご紹介しました。
- 100MB以上のファイルはLFSの仕組みを使わないと管理出来ない。
- GitHubの場合、LFSには若干の無償枠がある。しかし無償枠の消費後はデータ保存及びクローンで従量課金となるためご利用は計画的に！
最後までご覧いただきありがとうございました。
コメント