お得なのかな？

状況によりけりです。 S3のインターネットアウトが多いと結局割高な感じ。

容量指定でgit lfs trackは出来ないの？

出来ないため、名前でtrackを指定してください。かといっても”*.exe”のように指定してしまうと、軽量なexeファイルもLFS管理ファイルになるので、具体的な名前、パスで指定しましょう。

Git LFSをうまく使いこなそう

LFS（Git Large File Storage）の概要説明します。

需要あるかわかりませんが、最近はGitHubも勉強しているため、自己啓発も兼ねて書いていきます。

Git LFSの説明
GitHubの場合（使い方や制限等）

GitHubだと100MByte以上のファイルはLFSの仕組みを使わないと登録できません。覚えておいて損はないと考えます。

以下、目次となります！

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の場合

GitHubでLFSについて

公式サイトの関連記事はこの辺りでしょうか。

Git Large File Storageについて - GitHub Docs

GitHub には、リポジトリで許可されるファイルのサイズに制限があります。この制限を超えるファイルを追跡するには、Git Large File Storage を使います。

数値関係をまとめておきますね（2023年時点）。

プラン	1ファイル辺りの容量制限	LFSストレージ (無償枠)	LFS帯域 (無償枠)	LFS利用時の最大ファイルサイズ
Github.com (Free)	100MB以上はだめ。	1GB	1GB	2GB
Github.com (Team)	100MB以上はだめ。	1GB	1GB	4GB
GitHub enterprise Cloud	100MB以上はだめ。	1GB	12GB	5GB
GitHub enterprise Server	特になし。（設定値を設けることも可）	ー	ー	？

LFSストレージ、LFS帯域については後述します。

GitHubのPublicリポジトリだと色々な機能が無償で使えることがありますが、LFSはPublicリポジトリでもPrivateリポジトリと同じ制限です！

※Enterprise Cloudの場合はOrganizationの合計値になります。
→ Enterpriseで利用人数が増えようが、同じ値です！

以下はLFSに関する警告やエラー例です。

GitHub Desktopを利用している場合、コミット段階で次の警告が表示されます。

警告を無視してコミット後にプッシュすると、アップロードが終わった段階でErrorが表示されます（すぐにErrorにならない）。

なお、公式マニュアルによると、ファイル容量50MBを超えた段階で、GitHubから警告がくるようです。

LFSストレージとは？

LFSを利用するファイルの格納場所（ストレージ）です。

例えば、無償枠が「1GB」であれば、合計1GBのファイルが置けます。
つまり、100MBのファイルを10個格納したら、LFSストレージは一杯です。

LFS帯域とは？

LFSストレージからファイルをダウンロードした転送量のことです。

「LFSサーバ」 → 「自分のPC」
等の転送時にLFS帯域を消費します。

※アップロードは対象外です。

AWSのアウトバンド転送でコストが発生しますが、同等の考え方です。

例えば、無償枠が「1GB」であれば、合計1GB分は無償でダウンロードできます。
つまり、100MBのファイルを10個ダウンロードすると、無償枠はすっからかんです。

Publicだとやばいかな？

一般利用者のダウンロードですぐに消費かな。EDos？

課金について

データパック

LFSストレージやLFS帯域は「データパック」を購入することで追加出来ます。

Git Large File Storage をアップグレードする - GitHub Docs

追加のデータパックを購入すると、Git LFS の毎月の帯域幅容量と総ストレージ容量を増やすことができます。

1パック5USD

50GBのLFSストレージ
50GBのLFS帯域

です。

Enterpriseの場合は、年間購入っぽいです（実際に購入したことは無くてEnterpriseを試験運用したときに確認）。

・・・ところで将来的にGitHubのLFSは従量課金制になるようです（後述）。

従量課金

2024年6月2日以降のEnterpriseは従量課金のようです。

Git Large ファイルストレージの拡張請求について - GitHub Enterprise Cloud Docs

Git Large File Storage の請求について説明します。

パック購入の手間がないですし、使った分だけの請求なため明瞭です。

今のところEnterprise限定のように読める。
帯域コスト（GiB辺り）：0.0875$
ストレージコスト（月GiB辺り）：0.07$
Actionsなどと同じように制限値を設定可能。

LFSのサーバは自前でも準備できる

自前で準備も出来るようです。

例えば、LFSサーバをAWSのS3とする場合ですね。
→ 詳しくはググると、先輩方の実施記事がいくつも見つかりました。

Q お得なのかな？: A

状況によりけりです。
S3のインターネットアウトが多いと結局割高な感じ。

管理を気を付けないと、面倒な割に、それなりに高額になりそうです。
※S3ファイルのダウンロードがインターネットになる場合、データパックを購入するのと同じぐらいのコストです。

操作例

LFSをサポートしているGitホスティングサーバは結構ありますが、今回はGitHubを使いました。

全体的な流れ

git lfs導入
git lfs対象ファイル設定
後はいつも通り、commit＆pushすればOK

初期設定とプッシュまで

git lfsを導入していない場合は、別途導入しましょう。

Windowsであれば、以下からGitをデフォルトでインストールすれば入ります。

Git - Downloads

対象ファイルの設定は次の通り。

Git Large File Storage を設定する - GitHub Docs

Git LFS をインストールしたら、それをリポジトリ内の大容量ファイルに関連付ける必要かあります。

<リポジトリ内で初期設定>
$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

LFSの初期設定操作は代表者が最初に行えればOKです。
→ .gitattributesも一緒にリポジトリに入れば、他のクライアントでも同様に動作します（ただしlfsは必要）。

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 -- %f

任意Clone時にLFSダウンロードを対象外にしたい

GIT_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 :/'