這個(gè)問題的解決方案隨時(shí)間而發(fā)展，但是目前還沒有明確的勝者。競爭者如下：

Git LFS，GitHub支持。

GitAnnex，GitLab支持，但只是企業(yè)版。

Git Annex更加成熟。這兩個(gè)方案都開源并通過Git的插件機(jī)制實(shí)現(xiàn)。

還存在著一些其他的系統(tǒng)，這表明它是當(dāng)前Git的一個(gè)尚未解決的痛點(diǎn)。Git Annex在http：//git - annex .branchable．com/not/上比較了不同的方案。

【如果需要對(duì)媒體文件進(jìn)行版本控制，你應(yīng)該開始考察Git Annex。

它用Haskell編寫并且包含在許多發(fā)行版的包管理系統(tǒng)里。

還需注意的是這種方案的主要優(yōu)勢(shì)是對(duì)媒體文件和相對(duì)應(yīng)的代碼，一起進(jìn)行版本控制的能力。當(dāng)與代碼一起時(shí)，你可以很方便地檢查不同版本間的代碼。檢查媒體文件的不同更難并且用處不太大。

簡而言之，Git Annex在數(shù)據(jù)邏輯問題上使用了成熟的方案；增加一個(gè)間接層。通過在代碼庫里存儲(chǔ)文件的符號(hào)鏈接來實(shí)現(xiàn)。二進(jìn)制文件被存放在文件系統(tǒng)里并被本地工作區(qū)以如rsync的其他方式所用。創(chuàng)建這個(gè)解決方案當(dāng)然需要更多的工作量。】