Git 系列(七):使用 Git 管理二進位大對象
似乎大家都認可的事就是 Git 對於大的二進位對象文件支持得不好。要記住,二進位大對象與大文本文件是不同的。雖然 Git 對大型的文本文件版本控制毫無問題,但是對於不透明的二進位文件起不了多大作用,只能把它當作一個大的實體黑盒來提交。
設想這樣的場景,有一個另人興奮的第一人稱解密遊戲,您正在為它製作複雜的 3D 建模,源文件是以二進位格式保存的,最後生成一個 1GB 大小的的文件。您提交過一次,在 Git 源倉庫歷史中有一個 1GB 大小的新增提交。隨後,您修改了下模型人物的頭髮造型,然後提交更新,因為 Git 並不能把頭髮從頭部及模型中其餘的部分離開來,所以您只能又提交 1GB 的量。接著,您改變了模型的眼睛顏色,提交這部分更新:又是 GB 級的提交量。對一個模型的一些微小修改,就會導致三個 GB 級的提交量。對於想對一個遊戲所有資源進行版本控制這樣的規模,這是個嚴重的問題。
不同的是如 .obj
這種格式的文本文件,和其它類型文件一樣,都是一個提交就存儲所有更新修改狀態,不同的是 .obj
文件是一系列描述模型的純文本行。如果您修改了該模型並保存回 .obj
文件,Git 可以逐行讀取這兩個文件,然後創建一個差異版本,得到一個相當小的提交。模型越精細,提交就越小,這就是標準的 Git 用例。雖然文件本身很大,但 Git 使用覆蓋或稀疏存儲的方法來構建當前數據使用狀態的完整描述。
然而,不是所有的都是純文本的,但都要使用 Git,所以需要解決方案,並且已經出現幾個了。
OSTree 開始是作為 GNOME 項目出現的,旨在管理操作系統的二進位文件。它不適用於這裡,所以我直接跳過。
Git 大文件存儲(LFS) 是放在 GitHub 上的一個開源項目,是從 git-media 項目中分支出來的。git-media 和 git-annex 是 Git 用於管理大文件的擴展。它們是對同一問題的兩種不同的解決方案,各有優點。雖然它們都不是官方的項目,但在我看來,每個都有獨到之處:
- git-media 是集中模式,有一個公共資產的存儲庫。你可以告訴 git-media 大文件需要存儲的位置,是在硬碟、伺服器還是在雲存儲伺服器,項目中的每個用戶都將該位置視為大型文件的中心主存儲位置。
- git-annex 側重於分布模式。用戶各自創建存儲庫,每個存儲庫都有一個存儲大文件的本地目錄
.git/annex
。這些 annex 會定期同步,只要有需要,每個用戶都可以訪問到所有的資源。除非通過 annex-cost 特別配置,否則 git-annex 優先使用本地存儲,再使用外部存儲。
對於這些,我已經在生產中使用了 git-media 和 git-annex,那麼下面會向你們概述其工作原理。
git-media
git-media 是使用 Ruby 語言開發的,所以首先要安裝 gem(LCTT 譯註:Gem 是基於 Ruby 的一些開發工具包)。安裝說明在其網站上。想使用 git-meida 的用戶都需要安裝它,因為 gem 是跨平台的工具,所以在各平台都適用。
安裝完 git-media 後,你需要設置一些 Git 的配置選項。在每台機器上只需要配置一次。
$ git config filter.media.clean "git-media filter-clean"
$ git config filter.media.smudge "git-media filter-smudge"
在要使用 git-media 的每個存儲庫中,設置一個屬性以將剛剛創建的過濾器結合到要您分類為「 媒體 」的文件類型里。別被這種術語混淆。一個更好的術語是「資產」,因為「媒體」通常的意思是音頻、視頻和照片,但您也可以很容易地將 3D 模型,烘焙和紋理等歸類為媒體。
例如:
$ echo "*.mp4 filter=media -crlf" >> .gitattributes
$ echo "*.mkv filter=media -crlf" >> .gitattributes
$ echo "*.wav filter=media -crlf" >> .gitattributes
$ echo "*.flac filter=media -crlf" >> .gitattributes
$ echo "*.kra filter=media -crlf" >> .gitattributes
當您要 暫存 這些類型的文件時,文件會被複制到 .git/media
目錄。
假設在伺服器已經有了一個 Git 源倉庫,最後一步就告訴源倉庫「母艦」所在的位置,也就是,當媒體文件被推送給所有用戶共享時,媒體文件將會存儲的位置。這在倉庫的 .git/config
文件中設置,請替換成您的用戶名、主機和路徑:
[git-media]
transport = scp
autodownload = false #默認為 true,拉取資源
scpuser = seth
scphost = example.com
scppath = /opt/jupiter.git
如果您的伺服器上 SSH 設置比較複雜,例如使用了非標準埠或非默認 SSH 密鑰文件的路徑,請使用 .ssh/config
為主機設置默認配置。
git-media 的使用和普通文件一樣,可以把普通文件和 blob 文件一樣對待,一樣進行 commit 操作。操作流程中唯一的不同就是,在某些時候,您應該將您的資產(或稱媒體)同步到共享存儲庫中。
當要為團隊發布資產或自己備份資料時,請使用如下命令:
$ git media sync
要用一個變更後的版本替換 git-media 中的文件時(例如,一個已經美聲過的音頻文件,或者一個已經完成的遮罩繪畫,或者一個已經被顏色分級的視頻文件),您必須明確的告訴 Git 更新該媒體。這將覆蓋 git-media 不會複製遠程已經存在的文件的默認設置:
$ git update-index --really-refresh
當您團隊的其他成員(或是您本人,在其它機器上)克隆本倉庫時,如果沒有在 .git/config
中把 autodownload
選項設置為 true
的話,默認是不會下載資源的。但 git-media 的一個同步命令 git media sync
可解決所有問題。
git-annex
git-annex 的處理流程略微的有些不同,默認是使用本地倉庫的,但基本的思想都一樣。您可以從你的發行版的軟體倉庫中安裝 git-annex,或者根據需要從該網站上下載安裝。與 git-media 一樣,任何使用 git-annex 的用戶都必須在其機器上安裝它。
其初始化設置比 git-media 都簡單。運行如下命令,其中替換成您的路徑,就可以在您的伺服器上創建好裸存儲庫:
$ git init --bare --shared /opt/jupiter.git
然後克隆到本地計算機,把它標記為 git-annex 的初始路徑:
$ git clone seth@example.com:/opt/jupiter.clone
Cloning into 'jupiter.clone'...
warning: You appear to have clonedan empty repository.
Checking connectivity... done.
$ git annex init "seth workstation"
init seth workstation ok
不要使用過濾器來區分媒體資源或大文件,您可以使用 git annex
命令來配置歸類大文件:
$ git annex add bigblobfile.flac
add bigblobfile.flac
(checksum) ok
(Recording state in Git...)
跟普通文件一樣進行提交操作:
$ git commit -m 'added flac source for sound fx'
但是推送操作是不同的,因為 git annex
使用自己的分支來跟蹤資產。您首次推送可能需要 -u
選項,具體取決於您如何管理您的存儲庫:
$ git push -u origin master git-annex
To seth@example.com:/opt/jupiter.git
* [new branch] master -> master
* [new branch] git-annex -> git-annex
和 git-media 一樣,普通的 git push
命令是不會拷貝資料到伺服器的,僅僅只是發送了相關的消息,要真正共享文件,需要運行同步命令:
$ git annex sync --content
如果別人已經提交了共享資源,您需要拉取它們,git annex sync
命令將提示您要在本地檢出你本機沒有,但在伺服器上存在的資源。
git-media 和 git-annex 都非常靈活,都可以使用本地存儲庫來代替伺服器,所以它們也常用於管理私有的本地項目。
Git 是一個非常強大和擴展性非常強的系統應用軟體,我們應該毫不猶豫的使用它。現在就開始試試吧!
via: https://opensource.com/life/16/8/how-manage-binary-blobs-git-part-7
作者:Seth Kenlon 譯者:runningwater 校對:wxy
本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive