當前位置:
首頁 > 知識 > 通過 Git 來管理多媒體文件

通過 Git 來管理多媒體文件

在我們有關 Git 鮮為人知的用法系列的最後一篇文章中,了解如何使用 Git 跟蹤項目中的大型多媒體文件。

-- Seth Kenlon

Git 是專用於源代碼版本控制的工具。因此,Git 很少被用於非純文本的項目以及行業。然而,非同步工作流的優點是十分誘人的,尤其是在一些日益增長的行業中,這種類型的行業把重要的計算和重要的藝術創作結合起來,這包括網頁設計、視覺效果、視頻遊戲、出版、貨幣設計(是的,這是一個真實的行業)、教育……等等。還有許多行業屬於這個類型。

在這個 Git 系列文章中,我們分享了六種鮮為人知的 Git 使用方法。在最後一篇文章中,我們將介紹將 Git 的優點帶到管理多媒體文件的軟體。

Git 管理多媒體文件的問題

眾所周知,Git 用於處理非文本文件不是很好,但是這並不妨礙我們進行嘗試。下面是一個使用 Git 來複制照片文件的例子:

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

在這裡我們可以看到有些問題:刪除一個已經被提交的文件,還是會使得存儲庫的大小擴大到原來的 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 也允許通過 來遠程同步靜態資源,所以用戶可以設置一個遠程存儲位置,來做為一個中心的授權源。

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

安裝 Git-portal

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

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

使用 Git-portal

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

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

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

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

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

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

如果你忘記使用 Git-portal,那麼你需要手動刪除 下的文件:

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

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

增加 Git-portal 遠程位置

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

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

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

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

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

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

其他選擇

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

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

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

via:https://opensource.com/article/19/4/manage-multimedia-files-git

作者:Seth Kenlon選題:lujun9972譯者:svtter校對:wxy

本文由LCTT原創編譯,Linux中國榮譽推出

:看到這裡點一下在看唄?

喜歡這篇文章嗎?立刻分享出去讓更多人知道吧!


請您繼續閱讀更多來自 Linux中國 的精彩文章:

跟我學 「Linux」 小程序 Web 版開發(五):遇到的一些坑
NVIDIA 的雲遊戲服務 GeForce NOW 無恥地忽略了Linux