Git LFSとは
- Git LFS とは
- Git LFS のインストール
- 新しい Git LFS リポジトリの作成
- 既存の Git LFS リポジトリを複製します。
- 複製の高速化
- プルとチェックアウト
- プルの高速化
- Git LFS によるファイル追跡
- コミットとプッシュ
- ホスト間での Git LFS リポジトリの移動
- 追加の Git LFS 履歴の取得
- ローカルの Git LFS ファイルの削除
- サーバーからのリモート Git LFS ファイルの削除
- Git LFS オブジェクトを参照しているパスまたはコミットの検索
- Git LFS ファイルを含める/除外する
- Git LFS ファイルのロック
- Git LFS の仕組み
Git LFS とは何ですか?
Git は分散バージョン管理システムです。つまり、リポジトリの全履歴が複製作成プロセス中にクライアントに転送されます。大きなファイルを含むプロジェクト、特に定期的に変更される大きなファイルの場合、すべてのファイルのすべてのバージョンをクライアントがダウンロードする必要があるため、この初期の複製には膨大な時間がかかります。Git LFS (Large File Storage) は、Atlassian、GitHub、およびその他のオープンソース提供者によって開発された Git 拡張モジュールで、関連するバージョンを遅れてダウンロードすることによって、大容量ファイルがご使用のリポジトリに及ぼす影響を軽減します。具体的には、複製やフェッチ中ではなく、チェックアウト処理中に大きなファイルがダウンロードされます。
Git LFS は、リポジトリ内の大きなファイルを小さなポインタファイルに置き換えることでこれを行います。通常の使用時には Git LFS によって自動的に処理されるため、これらのポインタファイルは決して表示されません。
1. リポジトリにファイルを追加すると、Git LFS はそのコンテンツをポインターで置き換え、ファイルの内容をローカルの Git LFS キャッシュに保存します。
関連資料
Git リポジトリ全体を移動する方法
ソリューションを見る
Bitbucket Cloud での Git の使用方法についてのチュートリアルです。
2. 新しいコミットをサーバーにプッシュすると、新しくプッシュされたコミットによって参照される Git LFS ファイルは、ローカルの Git LFS キャッシュから、ユーザーの Git リポジトリに関連付けられたリモートの Git LFS ストアに転送されます。
Git LFS ポインタを含むコミットをチェックアウトすると、ポインタはローカルの Git LFS キャッシュからのファイルに置き換えられるか、リモートの Git LFS ストアからダウンロードされます。
Git LFS はシームレスです。作業コピーには実際のファイルコンテンツのみ表示されます。つまり、既存の Git ワークフローを変更せずに Git LFS を使用することができます。ユーザーは単に git checkout、編集、git add、および git commit を通常どおり行うだけです。git clone と git pull 操作は大幅に高速になります。これは、これまでに存在したファイルのすべてのバージョンではなく、実際にチェックアウトするコミットによって参照される大きなファイルのバージョンのみをダウンロードするからです。
Git LFS を使用するには、Bitbucket Cloud や Bitbucket Data Center などの Git LFS 対応ホストが必要です。リポジトリ ユーザは、Git LFS コマンド ライン クライアントをインストールするか、Git LFS 対応の GUI クライアント (Sourcetree など) をインストールする必要があります。面白いことに、Sourcetree を発明したアトラシアンの開発者 Steve Streeting も、Git LFS プロジェクトの主要な貢献者です。そのため、Sourcetree と Git LFS はうまく連携しています。
Git LFS のインストール
1. Git LFS をインストールするには、３つの簡単な方法があります。
a. お気に入りのパッケージマネージャーを使用してインストールします。git-lfs パッケージは、Homebrew、MacPorts、dnf、および packagecloud で利用できます。または
b. プロジェクトの Web サイトから Git LFS をダウンロードしてインストールします。
c. Sourcetree をインストールします。これは、Git LFS にバンドルされている無料の Git GUI クライアントです。
2. git-lfs がパス上に配置されたら、git lfs install を実行して Git LFS を初期化します（Sourcetree をインストールした場合はこの手順を省略できます）。
$ git lfs install Git LFS initialized. git lfs install は一度実行するだけで済みます。ユーザーのシステム用に初期化された後は、Git LFS コンテンツを含むリポジトリを複製すると、Git LFS が自動的にブートストラップします。
新しい Git LFS リポジトリの作成
新しい Git LFS 対応リポジトリを作成するには、リポジトリの作成後に git lfs install を実行する必要があります。
# initialize Git
$ mkdir Atlasteroids
$ cd Atlasteroids
$ git init
Initialized empty Git repository in /Users/tpettersen/Atlasteroids/.git/
# initialize Git LFS
$ git lfs install
Updated pre-push hook.
Git LFS initialized.これにより、ローカルのリポジトリに特別な pre-push Git フック がインストールされます。この特別なフックは、git push の実行時に Git LFS ファイルをサーバーに転送します。
Git LFS は、すべての Bitbucket Cloud リポジトリに対して自動的に有効になります。Bitbucket Data Center では、リポジトリ設定で Git LFS を有効にする必要があります。
Git LFS がローカルのリポジトリ用に初期化されると、git lfs track を使用して追跡するファイルを指定できるようになります。
既存の Git LFS リポジトリを複製します。
Git LFS がインストールされたら、git clone を使用して通常どおり Git LFS リポジトリを複製できます。複製プロセスの最後に、Git は既定のブランチ (通常は main) をチェックアウトします。チェックアウト プロセスを完了するために必要な Git LFS ファイルは自動的にダウンロードされます。例:
$ git clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 31.00 KiB/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Downloading Assets/Sprites/projectiles-spritesheet.png (21.14 KB)
Downloading Assets/Sprites/productlogos_cmyk-spritesheet.png (301.96 KB)
Downloading Assets/Sprites/shuttle2.png (1.62 KB)
Downloading Assets/Sprites/space1.png (1.11 MB)
Checking out files: 100% (81/81), done.Git LFS によって追跡されるこのリポジトリには、４つのPNG があります。git clone を実行すると、Git LFS ファイルは、ポインタファイルがリポジトリからチェックアウトされるときに１つずつダウンロードされます。
複製の高速化
多数の LFS ファイルがあるリポジトリを複製している場合、明示的な git lfs clone コマンドを使用すると、パフォーマンスがはるかに向上します。
$ git lfs clone git@bitbucket.org:tpettersen/Atlasteroids.git
Cloning into 'Atlasteroids'...
remote: Counting objects: 156, done.
remote: Compressing objects: 100% (154/154), done.
remote: Total 156 (delta 87), reused 0 (delta 0)
Receiving objects: 100% (156/156), 54.04 KiB | 0 bytes/s, done.
Resolving deltas: 100% (87/87), done.
Checking connectivity... done.
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MBgit lfs clone コマンドは、一度に1つずつ Git LFS ファイルをダウンロードするのではなく、チェックアウトが完了するまで待ってから、必要な Git LFS ファイルをバッチとしてダウンロードします。これにより、並列化ダウンロードが利用され、生成されるHTTP 要求とプロセスの数が大幅に削減されます (Windowsのパフォーマンスを向上させる上で特に重要です)。
プルとチェックアウト
複製と同じように、通常の git pull を使用して Git LFS リポジトリからプルできます。プルが完了すると、必要な Git LFS ファイルは自動チェックアウトプロセスの一部としてダウンロードされます。
$ git pull
Updating 4784e9d..7039f0a
Downloading Assets/Sprites/powerup.png (21.14 KB)
Fast-forward
Assets/Sprites/powerup.png | 3 +
Assets/Sprites/powerup.png.meta | 4133 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 4136 insertions(+)
create mode 100644 Assets/Sprites/projectiles-spritesheet.png
create mode 100644 Assets/Sprites/projectiles-spritesheet.png.metaGit LFS コンテンツを取得するための明示的なコマンドは必要ありません。ただし、予期せぬ理由でチェックアウトに失敗した場合は、git lfs pull を使用して、現在のコミットに関して欠落している Git LFS コンテンツをダウンロードできます。
$ git lfs pull
Git LFS: (4 of 4 files) 1.14 MB / 1.15 MBプルの高速化
git lfs clone と同様に、git lfs pull はあなたの Git LFS ファイルをバッチとしてダウンロードします。最後にプルしてから多数のファイルが変更されたことがわかっている場合は、チェックアウト時に自動 Git LFS のダウンロードを無効にしてから、Git LFS コンテンツを明示的に git lfs pull で一括ダウンロードできます。これは git pull を起動するときに -c オプションを指定して Git の設定をオーバーライドすることで実行できます。
$ git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull入力する項目が多いので単純な Git エイリアスを作成し、一括して Git と Git LFS プルを実行したいと考える場合もあるでしょう。
$ git config --global alias.plfs "\!git -c filter.lfs.smudge= -c filter.lfs.required=false pull && git lfs pull"
$ git plfsこれは、大量の Git LFS ファイルをダウンロードする必要があるとき (特にWindows上)、パフォーマンスを大幅に向上させます。
Git LFS によるファイル追跡
新しいタイプの大きなファイルをリポジトリに追加するときは、git lfs track コマンドを使用してパターンを指定することで、Git LFS にそれを追跡するように指示する必要があります。
$ git lfs track "*.ogg"
Tracking *.ogg"*.ogg" の引用符は重要であることに注意してください。引用符を省略すると、シェルによってワイルドカードが拡張され、現在のディレクトリの各 .ogg ファイルについて個別にエントリが作成されます。
# probably not what you want
$ git lfs track *.ogg
Tracking explode.ogg
Tracking music.ogg
Tracking phaser.oggGit LFS でサポートされているパターンは .gitignore でサポートされているパターンと同じです。以下に例を示します。
# track all .ogg files in any directory
$ git lfs track "*.ogg"
# track files named music.ogg in any directory
$ git lfs track "music.ogg"
# track all files in the Assets directory and all subdirectories
$ git lfs track "Assets/"
# track all files in the Assets directory but *not* subdirectories
$ git lfs track "Assets/*"
# track all ogg files in Assets/Audio
$ git lfs track "Assets/Audio/*.ogg"
# track all ogg files in any directory named Music
$ git lfs track "**/Music/*.ogg"
# track png files containing "xxhdpi" in their name, in any directory
$ git lfs track "*xxhdpi*.pngこれらのパターンは、git lfs track コマンドを実行したディレクトリへの相対パスです。物事を単純にするために、リポジトリのルートから git lfs track を実行するのが最善です。Git LFS は 否定パターン (.gitignore など) をサポートしていないことに注意してください。
git lfs track を実行すると、コマンドを実行したディレクトリに .gitattributes という名前の新しいファイルが作成されます。.gitattributes は特定の動作を特定のファイルパターンにバインドするための Git の仕組みです。Git LFS は .gitattributes ファイルを自動的に作成または更新して追跡したファイルパターンを Git LFS フィルターにバインドします。ただし、.gitattributes ファイルへの変更をご使用のリポジトリに自分でコミットする必要があります。
$ git lfs track "*.ogg"
Tracking *.ogg
$ git add .gitattributes
$ git diff --cached
diff --git a/.gitattributes b/.gitattributes
new file mode 100644
index 0000000..b6dd0bb
--- /dev/null
+++ b/.gitattributes
@@ -0,0 +1 @@
+*.ogg filter=lfs diff=lfs merge=lfs -text
$ git commit -m "Track ogg files with Git LFS"保守を容易にするために、すべての Git LFS パターンを単一の .gitattributes ファイルに保存するのが最も簡単です。これを実行するには、ご使用のリポジトリのルートから常に git lfs track を実行してください。一方、Git LFS (およびパターンが定義されている .gitattributes ファイル) によって現在追跡されているすべてのパターンのリストを表示することができます。これを実行するには、引数なしで git lfs track を呼び出します。
$ git lfs track
Listing tracked paths
*.stl (.gitattributes)
*.png (Assets/Sprites/.gitattributes)
*.ogg (Assets/Audio/.gitattributes).gitattributes ファイルから適切な行を削除するだけで、Git LFS による特定のパターンの追跡を止めることができます。または、git lfs untrack コマンドを実行します。
$ git lfs untrack "*.ogg"
Untracking *.ogg
$ git diff
diff --git a/.gitattributes b/.gitattributes
index b6dd0bb..e69de29 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -1 +0,0 @@
-*.ogg filter=lfs diff=lfs merge=lfs -textgit lfs untrack を実行した後、再度その変更を自分で .gitattributes にコミットする必要があります。
コミットとプッシュ
Git LFS コンテンツを含むリポジトリへのコミットとプッシュは通常どおりです。Git LFS により追跡されているファイルに変更をコミットした場合、Git LFS コンテンツがサーバーに転送されるときに、git push からの追加出力がいくつか表示されます。
$ git push
Git LFS: (3 of 3 files) 4.68 MB / 4.68 MB
Counting objects: 8, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.16 KiB | 0 bytes/s, done.
Total 8 (delta 1), reused 0 (delta 0)
To git@bitbucket.org:tpettersen/atlasteroids.git
7039f0a..b3684d3 main -> mainなんらかの理由で LFS ファイルの転送に失敗すると、プッシュは中止され、安全に再試行できます。Git と同様に、Git LFS ストレージはコンテンツのアドレス指定が可能です。コンテンツは、コンテンツ自体の SHA-256 ハッシュであるキーに対して保存されます。つまり、再試行で Git LFS ファイルをサーバーへ転送しても常に安全です。誤って Git LFS ファイルのコンテンツを間違ったバージョンで上書きすることはできません。
ホスト間での Git LFS リポジトリの移動
あるホスティングプロバイダーから別のホスティングプロバイダーに Git LFS リポジトリを移行するには、git lfs fetch と git lfs push を組み合わせて使用し、--all オプションを指定します。
たとえば、すべての Git および Git LFS リポジトリを github という名前のリモートから bitbucket という名前のリモートに移動するには 😉 :
# create a bare clone of the GitHub repository
$ git clone --bare git@github.com:kannonboy/atlasteroids.git
$ cd atlasteroids
# set up named remotes for Bitbucket and GitHub
$ git remote add bitbucket git@bitbucket.org:tpettersen/atlasteroids.git
$ git remote add github git@github.com:kannonboy/atlasteroids.git
# fetch all Git LFS content from GitHub
$ git lfs fetch --all github
# push all Git and Git LFS content to Bitbucket
$ git push --mirror bitbucket
$ git lfs push --all bitbucket追加の Git LFS 履歴の取得
Git LFS は通常、実際にローカルでチェックアウトしたコミットに必要なファイルのみをダウンロードします。ただし、git lfs fetch --recent を使用すると、最近変更された他のブランチのために追加のコンテンツをダウンロードするように Git LFS に強制できます。
$ git lfs fetch --recent
Fetching main
Git LFS: (0 of 0 files, 14 skipped) 0 B / 0 B, 2.83 MB skipped Fetching recent branches within 7 days
Fetching origin/power-ups
Git LFS: (8 of 8 files, 4 skipped) 408.42 KB / 408.42 KB, 2.81 MB skipped
Fetching origin/more-music
Git LFS: (1 of 1 files, 14 skipped) 1.68 MB / 1.68 MB, 2.83 MB skippedこれは、ランチに出かけている間、またはチームメートからの作業のレビューを計画しており、限られたインターネット接続のために後でコンテンツをダウンロードできない場合、新しい Git LFS コンテンツを一括してダウンロードするのに便利です。たとえば、飛行機に飛び乗る前に git lfs fetch --recent を実行する必要が生じるかもしれません！
Git LFS は、コミットを含むブランチやタグが作成されてから 7 日未満のものを最近とみなします。lfs.fetchrecentrefsdays プロパティを設定すると、最近とみなされる基準の日数を設定できます。
# download Git LFS content for branches or tags updated in the last 10 days
$ git config lfs.fetchrecentrefsdays 10既定では、git lfs fetch --recent は最近のブランチやタグの先端にあるコミットの Git LFS コンテンツのみをダウンロードします。
ただし、lfs.fetchrecentcommitsdays プロパティを設定することによって、最近のブランチやタグの以前のコミットのコンテンツをダウンロードするように Git LFS を設定することができます。
# download the latest 3 days of Git LFS content for each recent branch or tag
$ git config lfs.fetchrecentcommitsdays 3この設定は慎重に使用してください。ブランチを高速に移動すると、膨大な量のデータがダウンロードされる可能性があります。しかし、ブランチ上の割り込み変更を確認して、複数のブランチからコミットを選別する必要がある場合や、履歴の書き換えが必要な場合には役立ちます。
「ホスト間での Git LFS リポジトリの移動」で説明したように、ご使用のリポジトリのすべての Git LFS コンテンツは git lfs fetch --all を使用して取得することもできます。
$ git lfs fetch --all
Scanning for all objects ever referenced...
✔ 23 objects found
Fetching objects...
Git LFS: (9 of 9 files, 14 skipped) 2.06 MB / 2.08 MB, 2.83 MB skippedローカルの Git LFS ファイルの削除
git lfs prune コマンドを使用して、ローカルの Git LFS キャッシュからファイルを削除できます。
$ git lfs prune
✔ 4 local objects, 33 retained
Pruning 4 files, (2.1 MB)
✔ Deleted 4 filesこれにより、古いとみなされるローカルの Git LFS ファイルは削除されます。古いファイルは、以下のコミットにより参照されていないファイルです。
- 現在チェックアウト中のコミット
- (origin、または
lfs.pruneremotetocheckが設定されているものへ) まだプッシュされていないコミット - 最近のコミット
既定では、最近のコミットは過去 10 日間に作成されたコミットです。これは、以下を追加して計算されます。
lfs.fetchrecentrefsdaysプロパティの値 (これについては「追加の Git LFS 履歴の取得」で説明。既定値は 7)。lfs.pruneoffsetdaysプロパティの値 (既定値は 3)
Git LFS コンテンツを長期間保持できるよう prune offset を構成できます。
# don't prune commits younger than four weeks (7 + 21)
$ git config lfs.pruneoffsetdays 21Git に組み込まれているガベージ コレクションとは異なり、Git LFS コンテンツは自動的に prune 実行されないため、ローカル リポジトリのサイズを小さく抑えるには、git lfs prune を定期的に実行することをお勧めします。
git lfs prune --dry-run を使用して、prune 操作がどのような効果を持つかをテストできます。
$ git lfs prune --dry-run
✔ 4 local objects, 33 retained
4 files would be pruned (2.1 MB)そして、git lfs prune --verbose --dry-run を使用して、正確にはどの Git LFS オブジェクトが prune 実行されるのかをテストできます。
$ git lfs prune --dry-run --verbose
✔ 4 local objects, 33 retained
4 files would be pruned (2.1 MB)
* 4a3a36141cdcbe2a17f7bcf1a161d3394cf435ac386d1bff70bd4dad6cd96c48 (2.0 MB)
* 67ad640e562b99219111ed8941cb56a275ef8d43e67a3dac0027b4acd5de4a3e (6.3 KB)
* 6f506528dbf04a97e84d90cc45840f4a8100389f570b67ac206ba802c5cb798f (1.7 MB)
* a1d7f7cdd6dba7307b2bac2bcfa0973244688361a48d2cebe3f3bc30babcf1ab (615.7 KB)--verbose モードで出力される長い 16 進数の文字列は、prune 対象の Git LFS オブジェクトの SHA-256 ハッシュ (オブジェクト ID または OID とも呼ばれます) です。Git LFS オブジェクトを参照しているパスまたはコミットの検索で説明されている手法を使用して、prune 対象のオブジェクトの詳細を調べることができます。
追加の安全性チェックとして、--verify-remote オプションを使用して、リモートの Git LFS ストアに Git LFS オブジェクトのコピーがあるかどうかを prune 実行前に確認できます。
$ git lfs prune --verify-remote
✔ 16 local objects, 2 retained, 12 verified with remote
Pruning 14 files, (1.7 MB)
✔ Deleted 14 filesこれにより、prune プロセスが大幅に遅くなりますが、prune されたオブジェクトがすべてサーバーからリカバリ可能であることがわかるので安心できます。lfs.pruneverifyremotealways プロパティをグローバルに設定することで、--verify-remote オプションをシステムに対して永続的に有効にできます。
$ git config --global lfs.pruneverifyremotealways true または、上記のコマンドから --global オプションを省略して、コンテキスト リポジトリのみのリモート検証を有効にすることもできます。
サーバーからのリモート Git LFS ファイルの削除
Git LFS コマンド ライン クライアントはサーバーのファイルに対する prune をサポートしていないため、削除方法はホスティング プロバイダーによって異なります。
Bitbucket Cloud では、[リポジトリ設定] > [Git LFS] を選択して Git LFS ファイルを表示および削除できます。
各 Git LFS ファイルには SHA-256 OID によってインデックスが作成されます。各ファイルを参照するパスは UI には表示されません。その理由は、特定のオブジェクトを参照する多数の異なるコミットに多数の異なるパスが存在する可能性があり、それらを調べるとプロセスが非常に遅くなるためです。
特定の Git LFS ファイルに実際に何が含まれているかを調べるには、３つのオプションがあります。
- Bitbucket Git LFS UI の左側の列にあるファイル プレビュー画像とファイル タイプを確認します。
- Bitbucket Git LFS UI の右側の列にあるリンクを使用してファイルをダウンロードします。- 次のセクションで説明するように、Git LFS オブジェクトの SHA-256 OID を参照するコミットを検索します。
Git LFS オブジェクトを参照しているパスまたはコミットの検索
Git LFS SHA-256 OID がある場合、git log --all -p -S を使用して、どのコミットがそれを参照しているかを判断できます。
$ git log --all -p -S 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
commit 22a98faa153d08804a63a74a729d8846e6525cb0
Author: Tim Pettersen <tpettersen@atlassian.com>
Date: Wed Jul 27 11:03:27 2016 +1000
Projectiles and exploding asteroids
diff --git a/Assets/Sprites/projectiles-spritesheet.png
new file mode 100755
index 0000000..49d7baf
--- /dev/null
+++ b/Assets/Sprites/projectiles-spritesheet.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
+size 21647この定型の git log により、指定した文字列 (Git LFS SHA-256 OID) を含む行 (-S) を追加または削除する任意のブランチ (--all) のコミットからパッチ (-p) を生成します。
このパッチには、コミットと LFS オブジェクトへのパス、追加者、コミットされた日時が表示されます。コミットをチェック アウトするだけで、Git LFS により、必要に応じてファイルがダウンロードされ、作業コピーに配置されます。
特定の Git LFS オブジェクトが現在の HEAD または特定のブランチにあると思われる場合は、git grep を使用して、そのオブジェクトを参照するファイル パスを見つけることができます。
# find a particular object by OID in HEAD
$ git grep 3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc HEAD
HEAD:Assets/Sprites/projectiles-spritesheet.png:oid sha256:3b6124b8b01d601fa20b47f5be14e1be3ea7759838c1aac8f36df4859164e4cc
# find a particular object by OID on the "power-ups" branch
$ git grep e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4 power-ups
power-ups:Assets/Sprites/shield2.png:oid sha256:e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4HEAD または power-ups は、Git LFS オブジェクトを含む任意の ref、コミット、またはツリーで置き換えできます。
Git LFS ファイルを含める/除外する
状況によっては、特定のコミットで利用可能な Git LFS コンテンツのサブセットのみをダウンロードしたい場合があります。たとえば、単体テストを実行するように CI ビルドを設定する場合、必要なのはソース コードだけなので、コードのビルドに必要のない重いファイルを除外したい場合があります。
git lfs fetch -X (または --exclude) を使用して、パターンまたはサブディレクトリを除外できます。
$ git lfs fetch -X "Assets/**" また、特定のパターンまたはサブディレクトリのみを対象としたい場合もあります。たとえば、オーディオ・エンジニアは git lfs fetch-I（または --include）を使用して ogg ファイルと wav ファイルだけをフェッチできます。
$ git lfs fetch -I "*.ogg,*.wav" インクルードとエクスクルードを組み合わせると、インクルード パターンと一致し、かつ、エクスクルード パターンと一致しないファイルのみがフェッチされます。たとえば、次を使用すると、gif ファイルを除く Assets ディレクトリ内のすべてを取得できます。
$ git lfs fetch -I "Assets/**" -X "*.gif" インクルードとエクスクルードは、git lfs track および .gitignore と同じパターンをサポートします。lfs.fetchinclude および lfs.fetchexclude 設定プロパティを使用して、これらのパターンを特定のリポジトリに対して永続的に設定できます。
$ git config lfs.fetchinclude "Assets/**"
$ git config lfs.fetchexclude "*.gif"これらの設定は、--global オプションを追加することで、システム上のすべてのリポジトリに適用することもできます。
Git LFS ファイルのロック
残念ながら、バイナリ マージの競合を解決する簡単な方法はありません。Git LFS ファイル ロックを使用すると、拡張子またはファイル名でファイルをロックし、マージ中にバイナリ ファイルが上書きされることを回避できます。
LFS のファイル ロック機能を利用するには、まず Git に対してロック可能なファイル タイプを指定する必要があります。以下の例では、--lockable フラグが git lfs track コマンドに追加されています。このコマンドは PSD ファイルを LFS に保存するとともに、ロック可能としてマークします。
$ git lfs track "*.psd" --lockable次に、.gitattributes ファイルに以下を追加します。
*.psd filter=lfs diff=lfs merge=lfs -text lockableLFS ファイルに変更を加える準備をするには、lock コマンドを使用して、ファイルを Git サーバー上でロック済みとして登録します。
$ git lfs lock images/foo.psd
Locked images/foo.psdファイル ロックが不要になったら、Git LFS の unlock コマンドを使用して削除できます。
$ git lfs unlock images/foo.psdGit LFS ファイル ロックは、git push と同様に、--force フラグを使用して上書きできます。何が起こるかを完全に理解している場合以外は --force フラグを使用しないでください。
$ git lfs unlock images/foo.psd --forceこの記事を共有する
次のトピック
おすすめコンテンツ
次のリソースをブックマークして、DevOps チームのタイプに関する詳細や、アトラシアンの DevOps についての継続的な更新をご覧ください。
Bitbucket ブログ
DevOps ラーニング パス
