如何通過Git來管理多媒體文件

本篇內容介紹了“如何通過Git來管理多媒體文件”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Git 管理多媒體文件的問題

眾所周知，Git 用于處理非文本文件不是很好，但是這并不妨礙我們進行嘗試。下面是一個使用 Git 來復制照片文件的例子：

$ du -hs108K .$ cp ~/photos/dandelion.tif .$ git add dandelion.tif$ git commit -m 'added a photo'[master (root-commit) fa6caa7] two photos 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 dandelion.tif$ du -hs1.8M .

目前為止沒有什么異常。增加一個 1.8MB 的照片到一個目錄下，使得目錄變成了 1.8 MB 的大小。所以下一步，我們嘗試刪除文件。

$ git rm dandelion.tif$ git commit -m 'deleted a photo'$ du -hs828K .

在這里我們可以看到有些問題：刪除一個已經被提交的文件，還是會使得存儲庫的大小擴大到原來的 8 倍（從 108K 到  828K）。我們可以測試多次來得到一個更好的平均值，但是這個簡單的演示與我的經驗一致。提交非文本文件，在一開始花費空間比較少，但是一個工程活躍地時間越長，人們可能對靜態內容修改的會更多，更多的零碎文件會被加和到一起。當一個  Git 存儲庫變的越來越大，主要的成本往往是速度。拉取和推送的時間，從最初抿一口咖啡的時間到你覺得你可能斷網了。

靜態內容導致 Git 存儲庫的體積不斷擴大的原因是什么呢？那些通過文本的構成的文件，允許 Git  只拉取那些修改的部分。光柵圖以及音樂文件對 Git 文件而言與文本不同，你可以查看一下 .png 和 .wav 文件中的二進制數據。所以，Git  只不過是獲取了全部的數據，并且創建了一個新的副本，哪怕是一張圖僅僅修改了一個像素。

Git-portal

在實踐中，許多多媒體項目不需要或者不想追蹤媒體的歷史記錄。相對于文本或者代碼的部分，項目的媒體部分一般有一個不同的生命周期。媒體資源一般按一個方向產生：一張圖片從鉛筆草稿開始，以數字繪畫的形式抵達它的目的地。然后，盡管文本能夠回滾到早起的版本，但是藝術制品只會一直向前發展。工程中的媒體很少被綁定到一個特定的版本。例外情況通常是反映數據集的圖形，通常是可以用基于文本的格式（如  SVG）完成的表、圖形或圖表。

所以，在許多同時包含文本（無論是敘事散文還是代碼）和媒體的工程中，Git 是一個用于文件管理的，可接受的解決方案，只要有一個在版本控制循環之外的游樂場來給藝術家游玩就行。

Graphic showing relationship between art assets and Git

一個啟用這個特性的簡單方法是 Git-portal，這是一個通過帶有  Git 鉤子的 Bash 腳本，它可將靜態文件從文件夾中移出 Git 的范圍，并通過符號鏈接來取代它們。Git  提交鏈接文件（有時候稱作別名或快捷方式），這種符號鏈接文件比較小，所以所有的提交都是文本文件和那些代表媒體文件的鏈接。因為替身文件是符號鏈接，所以工程還會像預期的運行，因為本地機器會處理他們，轉換成“真實的”副本。當用符號鏈接替換出文件時，Git-portal  維護了項目的結構，因此，如果你認為 Git-portal  不適合你的項目，或者你需要構建項目的一個沒有符號鏈接的版本（比如用于分發），則可以輕松地逆轉該過程。

Git-portal 也允許通過 rsync 來遠程同步靜態資源，所以用戶可以設置一個遠程存儲位置，來做為一個中心的授權源。

Git-portal 對于多媒體的工程是一個理想的解決方案。類似的多媒體工程包括視頻游戲、桌面游戲、需要進行大型 3D 模型渲染和紋理的虛擬現實工程、帶圖以及 .odt 輸出的書籍、協作型的博客站點、音樂項目，等等。藝術家在應用程序中以圖層（在圖形世界中）和曲目（在音樂世界中）的形式執行版本控制并不少見——因此，Git  不會向多媒體項目文件本身添加任何內容。Git  的功能可用于藝術項目的其他部分（例如散文和敘述、項目管理、字幕文件、致謝、營銷副本、文檔等），而結構化遠程備份的功能則由藝術家使用。

安裝 Git-portal

Git-portal 的 RPM 安裝包位于 https://klaatu.fedorapeople.org/git-portal，可用于下載和安裝。

此外，用戶可以從 Git-portal 的 Gitlab 主頁手動安裝。這僅僅是一個 Bash 腳本以及一些 Git 鉤子（也是 Bash 腳本），但是需要一個快速的構建過程來讓它知道安裝的位置。

$ git clone https://gitlab.com/slackermedia/git-portal.git git-portal.clone$ cd git-portal.clone$ ./configure$ make$ sudo make install

使用 Git-portal

Git-portal 與 Git 一起使用。這意味著，如同 Git  的所有大型文件擴展一樣，都需要記住一些額外的步驟。但是，你僅僅需要在處理你的媒體資源的時候使用  Git-portal，所以很容易記住，除非你把大文件都當做文本文件來進行處理（對于 Git 用戶很少見）。使用 Git-portal  必須做的一個安裝步驟是：

$ mkdir bigproject.git$ cd !$$ git init$ git-portal init

Git-portal 的 init 函數在 Git 存儲庫中創建了一個 _portal 文件夾并且添加到 .gitignore 文件中。

在平日里使用 Git-portal 和 Git 協同十分平滑。一個較好的例子是基于 MIDI 的音樂項目：音樂工作站產生的項目文件是基于文本的，但是 MIDI 文件是二進制數據：

$ ls -1_portalsong.1.qtrsong.qtrsong-Track_1-1.midsong-Track_1-3.midsong-Track_2-1.mid$ git add song*qtr$ git-portal song-Track*mid$ git add song-Track*mid

如果你查看一下 _portal 文件夾，你會發現那里有最初的 MIDI 文件。這些文件在原本的位置被替換成了指向 _portal 的鏈接文件，使得音樂工作站像預期一樣運行。

$ ls -lG[...] _portal/[...] song.1.qtr[...] song.qtr[...] song-Track_1-1.mid -> _portal/song-Track_1-1.mid*[...] song-Track_1-3.mid -> _portal/song-Track_1-3.mid*[...] song-Track_2-1.mid -> _portal/song-Track_2-1.mid*

與 Git 相同，你也可以添加一個目錄下的文件。

$ cp -r ~/synth-presets/yoshimi .$ git-portal add yoshimiDirectories cannot go through the portal. Sending files instead.$ ls -lG _portal/yoshimi[...] yoshimi.stat -> ../_portal/yoshimi/yoshimi.stat*

刪除功能也像預期一樣工作，但是當從 _portal 中刪除一些東西時，你應該使用 git-portal rm 而不是 git rm。使用 Git-portal 可以確保文件從 _portal 中刪除：

$ ls_portal/    song.qtr             song-Track_1-3.mid@  yoshimi/song.1.qtr  song-Track_1-1.mid@  song-Track_2-1.mid@$ git-portal rm song-Track_1-3.midrm 'song-Track_1-3.mid'$ ls _portal/song-Track_1-1.mid*  song-Track_2-1.mid*  yoshimi/

如果你忘記使用 Git-portal，那么你需要手動刪除 _portal 下的文件：

$ git-portal rm song-Track_1-1.midrm 'song-Track_1-1.mid'$ ls _portal/song-Track_1-1.mid* song-Track_2-1.mid* yoshimi/$ trash _portal/song-Track_1-1.mid

Git-portal 其它的唯一功能，是列出當前所有的鏈接并且找到里面可能已經損壞的符號鏈接。有時這種情況會因為項目文件夾中的文件被移動而發生：

$ mkdir foo$ mv yoshimi foo$ git-portal statusbigproject.git/song-Track_2-1.mid: symbolic link to _portal/song-Track_2-1.midbigproject.git/foo/yoshimi/yoshimi.stat: broken symbolic link to ../_portal/yoshimi/yoshimi.stat

如果你使用 Git-portal 用于私人項目并且維護自己的備份，以上就是技術方面所有你需要知道關于 Git-portal 的事情了。如果你想要添加一個協作者或者你希望 Git-portal 來像 Git 的方式來管理備份，你可以創建一個遠程位置。

增加 Git-portal 遠程位置

為 Git-portal 增加一個遠程位置是通過 Git 已有的遠程功能來實現的。Git-portal 實現了 Git 鉤子（隱藏在存儲庫 .git 文件夾中的腳本），來尋找你的遠程位置上是否存在以 _portal 開頭的文件夾。如果它找到一個，它會嘗試使用 rsync 來與遠程位置同步文件。Git-portal 在用戶進行 Git 推送以及 Git 合并的時候（或者在進行 Git 拉取的時候，實際上是進行一次獲取和自動合并），都會執行此操作。

如果你僅克隆了 Git 存儲庫，那么你可能永遠不會自己添加一個遠程位置。這是一個標準的 Git 過程：

$ git remote add origin git@gitdawg.com:seth/bigproject.git$ git remote -vorigin git@gitdawg.com:seth/bigproject.git (fetch)origin git@gitdawg.com:seth/bigproject.git (push)

對你的主要 Git 存儲庫來說，origin 這個名字是一個流行的慣例，將其用于 Git  數據是有意義的。然而，你的 Git-portal 數據是分開存儲的，所以你必須創建第二個遠程位置來讓 Git-portal  了解向哪里推送和從哪里拉取。取決于你的 Git 主機，你可能需要一個單獨的服務器，因為空間有限的 Git 主機不太可能接受 GB  級的媒體資產。或者，可能你的服務器僅允許你訪問你的 Git 存儲庫而不允許訪問外部的存儲文件夾：

$ git remote add _portal seth@example.com:/home/seth/git/bigproject_portal$ git remote -vorigin git@gitdawg.com:seth/bigproject.git (fetch)origin git@gitdawg.com:seth/bigproject.git (push)_portal seth@example.com:/home/seth/git/bigproject_portal (fetch)_portal seth@example.com:/home/seth/git/bigproject_portal (push)

你可能不想為所有用戶提供服務器上的個人帳戶，也不必這樣做。為了提供對托管資源庫大文件資產的服務器的訪問權限，你可以運行一個 Git 前端，比如 Gitolite 或者你可以使用 rrsync （受限的 rsync）。

現在你可以推送你的 Git 數據到你的遠程 Git 存儲庫，并將你的 Git-portal 數據到你的遠程的門戶:

$ git push origin HEAD  master destination detectedSyncing _portal content...sending incremental file listsent 9,305 bytes  received 18 bytes  1,695.09 bytes/sectotal size is 60,358,015  speedup is 6,474.10Syncing _portal content to example.com:/home/seth/git/bigproject_portal

如果你已經安裝了 Git-portal，并且配置了 _portal 的遠程位置，你的 _portal 文件夾將會被同步，并且從服務器獲取新的內容，以及在每一次推送的時候發送新的內容。盡管你不需要進行 Git 提交或者推送來和服務器同步（用戶可以使用直接使用 rsync），但是我發現對于藝術性內容的改變，提交是有用的。這將會把藝術家及其數字資產集成到工作流的其余部分中，并提供有關項目進度和速度的有用元數據。

其他選擇

如果 Git-portal 對你而言太過簡單，還有一些用于 Git 管理大型文件的其他選擇。Git 大文件存儲（LFS）是一個名為 git-media 的停工項目的分支，這個分支由 GitHub 維護和支持。它需要特殊的命令（例如 git lfs track 來保護大型文件不被 Git 追蹤）并且需要用戶維護一個 .gitattributes 文件來更新哪些存儲庫中的文件被 LFS 追蹤。對于大文件而言，它僅支持 HTTP 和 HTTPS 遠程主機。所以你必須配置 LFS 服務器，才能使得用戶可以通過 HTTP 而不是 SSH 或 rsync 來進行鑒權。

另一個相對 LFS 更靈活的選擇是 git-annex。你可以在我的文章 管理 Git 中大二進制 blob  中了解更多（忽略其中 git-media 這個已經廢棄項目的章節，因為其靈活性沒有被它的繼任者 Git LFS 延續下來）。Git-annex   是一個靈活且優雅的解決方案。它擁有一個細膩的系統來用于添加、刪除、移動存儲庫中的大型文件。因為它靈活且強大，有很多新的命令和規則需要進行學習，所以建議看一下它的文檔。

然而，如果你的需求很簡單，你可能更加喜歡整合已有技術來進行簡單且明顯任務的解決方案，則 Git-portal 可能是對于工作而言比較合適的工具。

“如何通過Git來管理多媒體文件”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！