如何存盤 Git 大檔案？-有解無憂

本文主要講解在 Git 倉庫中如何管理大的二進制檔案，詳細介紹了什么是 Git LFS，Git LFS 是如何作業的，以及如何使用 Git LFS，

本文翻譯自 Atlassian 官方介紹 Git LFS 的文章，Atlassian 是 Git LFS 的主要開發者之一，這篇介紹 Git LFS 的文章比較權威，講的也很詳細，原文地址：

https://www.atlassian.com/git/tutorials/git-lfs

本文同時也加了我個人的一些注釋，注釋內容會明確用藍色字體標識出來，

什么是 Git LFS？

Git 是分布式 版本控制系統，這意味著在克隆程序中會將倉庫的整個歷史記錄傳輸到客戶端，對于包含大檔案（尤其是經常被修改的大檔案）的專案，初始克隆需要大量時間，因為客戶端會下載每個檔案的每個版本，Git LFS（Large File Storage）是由 Atlassian, GitHub 以及其他開源貢獻者開發的 Git 擴展，它通過延遲地（lazily）下載大檔案的相關版本來減少大檔案在倉庫中的影響，具體來說，大檔案是在 checkout 的程序中下載的，而不是 clone 或 fetch 程序中下載的（這意味著你在后臺定時 fetch 遠端倉庫內容到本地時，并不會下載大檔案內容，而是在你 checkout 到作業區的時候才會真正去下載大檔案的內容），

Git LFS 通過將倉庫中的大檔案替換為微小的指標（pointer） 檔案來做到這一點，在正常使用期間，你將永遠不會看到這些指標檔案，因為它們是由 Git LFS 自動處理的：

\1. 當你添加（執行 git add 命令）一個檔案到你的倉庫時，Git LFS 用一個指標替換其內容，并將檔案內容存盤在本地 Git LFS 快取中（本地 Git LFS 快取位于倉庫的.git/lfs/objects 目錄中），

\2. 當你推送新的提交到服務器時，新推送的提交參考的所有 Git LFS 檔案都會從本地 Git LFS 快取傳輸到系結到 Git 倉庫的遠程 Git LFS 存盤（即 LFS 檔案內容會直接從本地 Git LFS 快取傳輸到遠程 Git LFS 存盤服務器），

\3. 當你 checkout 一個包含 Git LFS 指標的提交時，指標檔案將替換為本地 Git LFS 快取中的檔案，或者從遠端 Git LFS 存盤區下載，

關于 LFS 的指標檔案：

LFS 的指標檔案是一個文本檔案，存盤在 Git 倉庫中，對應大檔案的內容存盤在 LFS 服務器里，而不是 Git 倉庫中，下面為一個圖片 LFS 檔案的指標檔案內容：

version https://git-lfs.github.com/spec/v1
oid sha256:5b62e134d2478ae0bbded57f6be8f048d8d916cb876f0656a8a6d1363716d999
size 285

指標檔案很小，小于 1KB，其格式為 key-value 格式，第一行為指標檔案規范 URL，第二行為檔案的物件 id，也即 LFS 檔案的存盤物件檔案名，可以在.git/lfs/objects 目錄中找到該檔案的存盤物件，第三行為檔案的實際大小（單位為位元組），所有 LFS 指標檔案都是這種格式，

Git LFS 是無縫的：在你的作業副本中，你只會看到實際的檔案內容，這意味著你不需要更改現有的 Git 作業流程就可以使用 Git LFS，你只需按常規進行 git checkout、編輯檔案、git add 和 git commit，git clone 和 git pull 將明顯更快，因為你只下載實際檢出的提交所參考的大檔案版本，而不是曾經存在過的檔案的每一個版本，

為了使用 Git LFS，你將需要一個支持 Git LFS 的托管服務器，例如Bitbucket Cloud或Bitbucket Server（GitHub、GitLab也都支持 Git LFS），倉庫用戶將需要安裝 Git LFS 命令列客戶端（參考這里其實更好），或支持 Git LFS 的 GUI 客戶端，例如Sourcetree，

安裝 Git LFS

\1. 有三種簡單的方式來安裝 Git LFS：

a. 用你最喜歡的軟體包管理器來安裝它，git-lfs 軟體包在 Homebrew，MacPorts，dnf 和packagecloud中都是可用的；或者

b. 從專案網站下載并安裝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 檔案到服務器上，

所有Bitbucket Cloud倉庫已自動啟用 Git LFS ，對于Bitbucket Server，你需要在倉庫設定中啟用 Git LFS：

當你的倉庫初始化了 Git LFS 后，你可以通過使用 git lfs track 來指定要跟蹤的檔案，

克隆現有的 Git LFS 倉庫

安裝 Git LFS 后，你可以像往常一樣使用 git clone 命令來克隆 Git LFS 倉庫，在克隆程序的結尾，Git 將檢出默認分支（通常是 master），并且將自動為你下載完成檢出程序所需的所有 Git LFS 檔案，例如：

$ git clone [email protected]:tpettersen/Atlasteroids.gitCloning 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

倉庫里有 4 個 PNG 檔案被 Git LFS 跟蹤，執行 git clone 命令時，在從倉庫中檢出指標檔案的時候，Git LFS 檔案被一個一個下載下來，

加快克隆速度

如果你正在克隆包含大量 LFS 檔案的倉庫，顯式使用 git lfs clone 命令可提供更好的性能：

$ git lfs clone [email protected]: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 MB

git lfs clone 命令不會一次下載一個 Git LFS 檔案，而是等到檢出（checkout）完成后再批量下載所有必需的 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.meta

不需要顯式的命令即可獲取 Git 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 pull 命令來批量下載 Git LFS 內容，而禁用在檢出期間自動下載 Git LFS，這可以通過在呼叫 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"周圍的引號很重要，省略它們將導致通配符被 shell 擴展，并將為當前目錄中的每個.ogg 檔案創建單獨的條目：

# probably not what you want
$ git lfs track *.ogg
Tracking explode.ogg
Tracking music.ogg
Tracking phaser.ogg

Git 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 那樣的負模式（negative patterns），

運行 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 track，將所有 Git LFS 模式保持在單個.gitattributes 檔案中是最簡單的，然而，你可以通過呼叫不帶引數的 git lfs track 命令來顯示 Git LFS 當前正在跟蹤的所有模式的串列（以及它們在其中定義的.gitattributes 檔案）：

$ git lfs track
Listing tracked paths
*.stl (.gitattributes)
*.png (Assets/Sprites/.gitattributes)
*.ogg (Assets/Audio/.gitattributes)

你可以通過從.gitattributes 檔案中洗掉相應的行，或者通過運行 git lfs untrack 命令來停止使用 Git LFS 跟蹤特定模式：

$ 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 -text

運行 git 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 master -> master

如果由于某些原因傳輸 LFS 檔案失敗，推送將被終止，你可以放心地重試，與 Git 一樣，Git LFS 存盤也是內容尋址 的（而不是按檔案名尋址）：內容是根據密鑰存盤的，該密鑰是內容本身的 SHA-256 哈希，這意味著重新嘗試將 Git LFS 檔案傳輸到服務器總是安全的；你不可能用錯誤的版本意外覆寫 Git LFS 檔案的內容，

在主機之間移動 Git LFS 倉庫

要將 Git LFS 倉庫從一個托管提供者遷移到另一個托管提供者，你可以結合使用指定了-all 選項的 git lfs fetch 和 git lfs push 命令，

例如，要將所有 Git 和 Git LFS 倉庫從名為github的遠端移動到名為bitbucket 的遠端：

# create a bare clone of the GitHub repository
$ git clone --bare [email protected]:kannonboy/atlasteroids.git
$ cd atlasteroids
# set up named remotes for Bitbucket and GitHub
$ git remote add bitbucket [email protected]:tpettersen/atlasteroids.git
$ git remote add github [email protected]: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 master
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

請謹慎使用此設定：如果分支移動很快，則可能會導致下載大量資料，但是，如果你需要查看分支上的插頁式更改，跨分支的 cherry-pick 提交或重寫歷史記錄，它可能會很有用，

如在主機之間移動 Git LFS 倉庫中所述，你還可以選擇使用 git lfs fetch --all 獲取倉庫的所有 Git LFS 內容：

$ 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 設定的）的提交
最近一次提交

默認情況下，最近的提交是最近十天內創建的任何提交，通過添加以下內容計算得出：

獲取額外的 Git LFS 歷史記錄中討論的 lfs.fetchrecentrefsdays 屬性的值（默認為 7）；至
lfs.pruneoffsetdays 屬性的值（默認為 3）

你可以配置 prune 偏移量以將 Git LFS 內容保留更長的時間：

# don't prune commits younger than four weeks (7 + 21)
$ git config lfs.pruneoffsetdays 21

與 Git 的內置垃圾收集不同，Git LFS 內容不會自動修剪，因此，定期運行 git lfs prune 命令是保持本地倉庫大小減小的好主意，

你可以使用 git lfs prune --dry-run 來測驗修剪操作將產生什么效果：

$ 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 物件將被修剪：

$ 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 模式輸出的長十六進制字串是要修剪的 Git LFS 物件的 SHA-256 哈希（也稱為物件 ID 或 OID），你可以使用“查找路徑”中描述的技識訓參考 Git LFS 物件的提交來查找有關將被修剪的物件的更多資訊，

作為附加的安全檢查，你可以使用--verify-remote 選項在洗掉之前，檢查遠程 Git LFS 存盤區是否具有你的 Git LFS 物件的副本：

$ git lfs prune --verify-remote
? 16 local objects, 2 retained, 12 verified with remote
Pruning 14 files, (1.7 MB)
? Deleted 14 files

這將使修剪程序明顯變慢，但是你可以從服務器上恢復所有修剪的物件，從而使你高枕無憂，你可以通過全域配置 lfs.pruneverifyremotealways 屬性為系統永久啟用--verify-remote 選項：

$ git config --global lfs.pruneverifyremotealways true

或者，你可以通過省略上述命令中的--global 選項，僅對當前倉庫啟用遠端校驗，

從服務器洗掉遠端 Git LFS 檔案

Git LFS 命令列客戶端不支持洗掉服務器上的檔案，因此如何洗掉他們取決于你的托管服務提供商，

在 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 <[email protected]>
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:e88868213a5dc8533fc9031f558f2c0dc34d6936f380ff4ed12c2685040098d4

你可以用任何包含 Git LFS 物件的 ref，commit 或 tree 替換 HEAD 或 power-ups，

包含/排除 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"

如果你將包含和排除合并在一起使用，則只會獲取與包含模式匹配，但與排除模式不匹配的檔案，例如，你可以使用以下方法獲取 Assets 目錄中除 gif 檔案之外的所有內容：

$ 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 哪些型別的檔案是可鎖定的，在下面的示例中，在 git lfs track 命令后附加了--lockable 標志，該命令既將 PSD 檔案存盤在 LFS 中，又將它們標記為可鎖定，

$ git lfs track "*.psd" --lockable

然后將以下內容添加到.gitattributes 檔案中：

*.psd filter=lfs diff=lfs merge=lfs -text lockable

在準備對 LFS 檔案進行更改時，你將使用 lock 命令以便將檔案在 Git 服務器上注冊為鎖定的檔案，

$ git lfs lock images/foo.psd
Locked images/foo.psd

一旦不再需要檔案鎖定，你可以使用 Git LFS 的 unlock 命令將其移除，

$ git lfs unlock images/foo.psd

與 git push 類似，可以使用--force 標志覆寫 Git LFS 檔案鎖，除非你完全確定自己在做什么，否則不要使用--force 標志，

$ git lfs unlock images/foo.psd --force

Git LFS 如何作業

如果你想了解有關 clean 和 smudge filter，pre-push 鉤子以及 Git LFS 背后的其他有趣的計算機科學的更多資訊，請網路上搜索查看 Atlassian 在 LinuxCon 2016 的 Git LFS 的演示文稿，

作者：terryshchen

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/How-do-I-store-large-Git-files.html

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/540712.html

標籤：其他

上一篇：如何存盤 Git 大檔案？

下一篇：當專案經理看世界杯決賽時…