3D遊戲開發團隊使用git進行版本控制時，怎麼處理二進位文件？

01-29

是不是可以對二進位文件運用一個過濾器，提煉出EXIF信息，也就是元數據，然後用exiftool程序參照元數據把圖像轉換成文本。這種方法可行嗎？或者使用git-annex，git-bigfiles?
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Perforce 公司的git Fusion怎麼樣？

3D遊戲一般不用JPEG……版本控制的都是源文件，常見的是PSD，然後自動轉換成平台格式。

另外元數據只是圖像的額外信息，轉成文本是為了diff這些信息么？

最後，許多遊戲公司採用Perforce來做版本控制。

反正JPEG只有美工改，又不存在diff的問題，為什麼要關心這些，直接commit就好了。

我覺得你要擔心的是，連github也承認的，git repo超過1G就會傻逼的問題。一個遊戲想突破這個界限簡直不需要懷疑。

Perforce吧，有不錯的界面化操作軟體P4V，和管理軟體P4A，搭建容易，低於20人團隊免費，Windows／Mac支持。集中式的版本管理對於東西的安全性也比較好保證。

Git的優勢是分散式，理念先進，然後在本地Get的話會比較快，在網路問題比較大的情況下據說很好，但是個人感覺麻煩，總是擔心到底可靠不可靠，有的時候太複雜的東西總會遇到一些莫名其妙難遇預料的小問題造成不必要的麻煩的。（比如你現在遇到的）

網路問題，如果要跨國合作什麼，介於我國蛋疼的網路問題，Perforce Subversion之類的集中式軟體得租個合適一些的伺服器，目前還是覺得租個國內的伺服器好，外國訪問貌似還算快的，租國外的總是不太穩定。（誰有好的辦法也請告訴我T T）

另外要考慮到學習成本，並不是所有人都會用項目管理軟體，或者有的項目管理軟體設計的也不一定很好用，大部分人也就當個FTP用。在遊戲開發這種項目里一大堆美術，程序，策劃等亂七八糟角色堆在一起的時候，經常會有人不懂怎沒用，或者覺得麻煩啥的不按照規範來搞，個人覺得P4這種有比較好GUI和原理比較簡單的工具更方便。

有點偏題了，當時也糾結了很久，就當分享下心得吧。

一般涉及到二進位文件，大多都是美術資源。而一般涉及到美術資源，都是美術方面的同事。

所以，這個問題很大程度上在問——美術人員如何處理git中的二進位文件。

我的建議是，不要讓美術碰git，所以題主說的那些個git 插件看起來美好，但都用不上。老老實實讓他們用perforce吧。要是沒錢，用svn也比git強。

Announcing Git Large File Storage (LFS) · GitHub

Distributed version control systems like Git have enabled new and powerful workflows, but they havent always been practical for versioning large files. Were excited to announce Git Large File Storage (LFS) as an improved way to integrate large binary files such as audio samples, datasets, graphics, and videos into your Git workflow.
Git LFS is a new, open source extension that replaces large files with text pointers inside Git, while storing the file contents on a remote server like http://GitHub.com or GitHub Enterprise.

Git Large File Storage

Select the file types youd like Git LFS to manage (or directly edit your .gitattributes). You can configure additional file extensions at anytime.

git lfs track "*.psd"
There is no step three. Just commit and push to GitHub as you normally would.
git add file.psd git commit -m "Add design file" git push origin master

如果你一定要用 Git 解決，試試這個。

svn給美術策劃用, git給程序用

大文件該怎麼提還是怎麼提

對於svn來說, 中心化的系統, 客戶端的repo不會擴展太嚴重, 伺服器空間可以忽略不計

對於git來說, 時間長了repo變大很正常, rebase一下再gc就好

github出了lfs，你可以看看。開源，可以集成在git命令中，專門管理大文件

對美術資源的管理很能體現一個公司在項目管理上的經驗積累，暢遊的項目一般都會設立一個「資源策劃」的職位，專門處理項目中美術資源的入庫和更新，同時管理配套的數據表格。經驗表明，最好不要多人管理美術資源，更不要讓美術來管，美術使用的版本庫用以共享和檢索為主，和版本製作所使用的版本庫需分開

老老實實用subversion吧，不要為了用而用。首先問自己：git對開發效率有提升嗎？同一個辦公環境里需要用到分散式的版本控制嗎？有什麼開發流程上的問題或發布流程上的問題用subversion處理不了必須用到git嗎？