通過 Git 來管理多媒體檔案
在我們有關 Git 鮮為人知的用法系列的最後一篇文章中,瞭解如何使用 Git 跟蹤專案中的大型多媒體檔案。
Git 是專用於原始碼版本控制的工具。因此,Git 很少被用於非純文字的專案以及行業。然而,非同步工作流的優點是十分誘人的,尤其是在一些日益增長的行業中,這種型別的行業把重要的計算和重要的藝術創作結合起來,這包括網頁設計、視覺效果、視訊遊戲、出版、貨幣設計(是的,這是一個真實的行業)、教育……等等。還有許多行業屬於這個型別。
在這個 Git 系列文章中,我們分享了六種鮮為人知的 Git 使用方法。在最後一篇文章中,我們將介紹將 Git 的優點帶到管理多媒體檔案的軟體。
Git 管理多媒體檔案的問題
眾所周知,Git 用於處理非文字檔案不是很好,但是這並不妨礙我們進行嘗試。下面是一個使用 Git 來複制照片檔案的例子:
$ du -hs
108K .
$ 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 -hs
1.8M .
目前為止沒有什麼異常。增加一個 1.8MB 的照片到一個目錄下,使得目錄變成了 1.8 MB 的大小。所以下一步,我們嘗試刪除檔案。
$ git rm dandelion.tif
$ git commit -m 'deleted a photo'
$ du -hs
828K .
在這裡我們可以看到有些問題:刪除一個已經被提交的檔案,還是會使得儲存庫的大小擴大到原來的 8 倍(從 108K 到 828K)。我們可以測試多次來得到一個更好的平均值,但是這個簡單的演示與我的經驗一致。提交非文字檔案,在一開始花費空間比較少,但是一個工程活躍地時間越長,人們可能對靜態內容修改的會更多,更多的零碎檔案會被加和到一起。當一個 Git 儲存庫變的越來越大,主要的成本往往是速度。拉取和推送的時間,從最初抿一口咖啡的時間到你覺得你可能斷網了。
靜態內容導致 Git 儲存庫的體積不斷擴大的原因是什麼呢?那些通過文字的構成的檔案,允許 Git 只拉取那些修改的部分。光柵圖以及音樂檔案對 Git 檔案而言與文字不同,你可以檢視一下 .png 和 .wav 檔案中的二進位制資料。所以,Git 只不過是獲取了全部的資料,並且建立了一個新的副本,哪怕是一張圖僅僅修改了一個畫素。
Git-portal
在實踐中,許多多媒體專案不需要或者不想追蹤媒體的歷史記錄。相對於文字或者程式碼的部分,專案的媒體部分一般有一個不同的生命週期。媒體資源一般按一個方向產生:一張圖片從鉛筆草稿開始,以數字繪畫的形式抵達它的目的地。然後,儘管文字能夠回滾到早起的版本,但是藝術製品只會一直向前發展。工程中的媒體很少被繫結到一個特定的版本。例外情況通常是反映資料集的圖形,通常是可以用基於文字的格式(如 SVG)完成的表、圖形或圖表。
所以,在許多同時包含文字(無論是敘事散文還是程式碼)和媒體的工程中,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
_portal
song.1.qtr
song.qtr
song-Track_1-1.mid
song-Track_1-3.mid
song-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 yoshimi
Directories 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.mid
rm '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.mid
rm '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 status
bigproject.git/song-Track_2-1.mid: symbolic link to _portal/song-Track_2-1.mid
bigproject.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 -v
origin 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 -v
origin 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 detected
Syncing _portal content...
sending incremental file list
sent 9,305 bytes received 18 bytes 1,695.09 bytes/sec
total size is 60,358,015 speedup is 6,474.10
Syncing _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 可能是對於工作而言比較合適的工具。
via: https://opensource.com/article/19/4/manage-multimedia-files-git
作者:Seth Kenlon 選題:lujun9972 譯者:svtter 校對:wxy
訂閱“Linux 中國”官方小程式來檢視
相關文章
- 透過 Git 來管理多媒體檔案Git
- Android掃描多媒體檔案剖析Android
- git大檔案管理Git
- Oracle 通過儲存過程來生成CSV檔案Oracle儲存過程
- 自媒體多平臺同步,自媒體多平臺分發,自媒體多平臺管理
- 通過移動資料檔案來均衡檔案I/O
- 試論多媒體技術與專案管理(轉)專案管理
- 用 Git 來共享檔案Git
- 解決MPLAYER播放不了多媒體檔案的方法。
- 自媒體多平臺管理軟體,管理30+自媒體平臺,一鍵多發
- 在IDEA中通過Module管理多個專案Idea
- 通過媒體查詢來實現 WPF 響應式設計
- 【git】透過 .gitignore 檔案來忽略特定的目錄Git
- 通過專案管理軟體克服管理瓶頸的方法?專案管理
- git上傳過濾檔案Git
- 通過oracle event來dump資料檔案頭資訊Oracle
- Java 在Word中嵌入多媒體(視訊、音訊)檔案Java音訊
- 利用ATL實現QuickTime多媒體檔案播放 (轉)UI
- 用Git與GitHub來管理專案Github
- Laravel 圖片,媒體檔案管理擴充套件包推薦Laravel套件
- 通過Xtrabackup日誌來恢復檢查點檔案
- git 忽略已提交過的檔案Git
- 自媒體多平臺管理軟體,管理多個賬號進行釋出
- 通過配置檔案來修改WAS控制檯Session過期時間的方法Session
- 通過trace檔案重新建立控制檔案
- Spring MVC 通過 @PropertySource和@Value 來讀取配置檔案SpringMVC
- Linux 通過lseek()來實現檔案大小的設定Linux
- 調查顯示80%願意通過社交媒體來分享自己的健康資訊
- 我們如何通過Zoho Projects專案管理軟體制定專案溝通計劃?Project專案管理
- XviD4PSP for mac多媒體檔案格式轉換器Mac
- C# 提取Word中插入的多媒體檔案(視訊、音訊)C#音訊
- Google Git-Repo 多倉庫專案管理GoGit專案管理
- 順通訊息資源庫存管理系統檔案管理軟體
- 硬體銷售實施流程管理如何通過Zoho專案管理軟體實現?專案管理
- 搜狐號多賬號管理工具,管理多個自媒體賬號
- 通過配置檔案(.htaccess)實現檔案上傳
- 通過VuePress管理專案文件(二)Vue
- 通過VuePress管理專案文件(一)Vue