如何使用 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

當您要暫存

stage這些類型的文件時，文件會被複制到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 是一個很是強大和擴展性很是強的系統應用軟件，咱們應該堅決果斷的使用它。如今就開始試試吧！

原文來自：http://www.php230.com/1480419001.html

本文地址：http://www.linuxprobe.com/large-objects.html