我已經繼承了一箇中等大小的iOS項目 - 大約30000行代碼 - 它有一個精靈圖片資產數量。當然，我們使用Git/Github來scm。目前，這些圖像被包含在目錄樹中，因此被吸收到回購站中，從而使得開發成爲一件非常頭疼的事情。如何處理Git倉庫中的圖像？
我們有4個開發項目，有些是虛擬的。我發現將圖像移動到Dropbox，從iOS項目中引用它們，並保持東西的形狀。
有沒有人對此想法發表評論？你在Git scm設置中如何處理圖像/視頻/音頻文件？
實際上，我對此非常緊張;如果你想更新圖像，然後改變主意？或者，如果您需要使用舊圖像構建維護版本，該怎麼辦？
如果這確實是一個問題 - 我從來沒有見過這實際上是一個實踐中的問題，但我會聽取您的意見 - 爲什麼不使用一個回購的圖像，另一個爲一切其他？那麼你可以懶惰地同步圖像。
這可能有點痛苦，但我過去使用的是submodules圖像和媒體。這樣，如果你願意，你可以下載你的代碼而不需要獲取圖像，但你仍然可以保持圖像和媒體與你的代碼同步。當子模塊歷史記錄變得太大時，我們可以創建一個沒有歷史記錄的新記錄庫，並將舊子模塊換出新的子模塊。這樣，人們就可以與最新版本的媒體保持同步，而無需拉下完整的歷史記錄。
我們會經常從子模塊中開始使用我們視頻的綠色屏幕，因此我們可以在視頻處於最終形式之前開發視頻，但是一旦它被合成，我們將打破子模塊歷史並推出只有合成視頻的新子模塊。這樣可以避免每個視頻都有一個額外的副本，同時仍然允許您（如果需要的話，只需輕輕地手動轉換子模塊）即可獲取舊版本。
子模塊將增加您需要完成的工作量。如果您想對圖像提交更改，則需要在子模塊中更改它們，進行提交，推送，然後轉到父項目，將更改提交到子模塊，然後推送。對於簡單的情況，您可以編寫一些腳本以使其更容易一些，但是在更復雜的情況下（例如合併衝突），比使用單個項目完成任何事情都要複雜得多。
我發現git在處理二進制源時是工作的錯誤工具。
您的軟件需要的最終資產才能被視爲「完整」，最好在您的回購協議中保持不變，但我會尋求替代解決方案來處理實際圖像源，例如ai文件或psd。
Git對這些文件的使用幾乎沒有任何好處，正如您所說的那樣，它會使回購負面影響git提供實際利益的領域。
我自己已經考慮過dropbox，但我覺得需要更多定製的解決方案。一個允許我跨計算機快速同步，自動存儲最近十個版本，允許我保留和命名特定版本並支持鎖定文件（閱讀：避免需要嘗試和合並二進制文件。）這是一個不同的工具爲不同的工作/工作流程。可悲的是，我不知道它的存在，但我很樂意看到它的存在。
只是回購中的最終作品。 .ai文件沒有.psd。 – dugla 2011-04-22 15:32:23
是的，在這種情況下，我只會保留在回購站或稍後抱歉：/。如果真的有很多，你可以使用一個git子模塊（http://bit.ly/aDvmTJ）來遏制瘋狂。此外，做一個審計，實際上正在使用或提供價值。如果它變成一堆垃圾刪除的東西。 – 2011-04-22 15:39:11
我自己並沒有使用它，但有一個名爲git media的項目，它的設計目的是讓它更容易處理像git中的圖像這樣的大二進制文件。這是Scott Chacon在git世界中的一個大問題，所以我想它可能工作得很好。
您可以使用Subversion系統（SVN）存儲圖像和二進制文件。圖像和其他二進制文件不會經常更改，但是當這些文件發生更改或集中更新時，您仍然可以得到通知。
Git最適合僅版本源代碼，並且只包含Github中的源代碼。
Subversion和Git在一起可以給你所有東西的總版本。
我一直對這個問題感興趣。在我的曲折中，我遇到了git附件：http://git-annex.branchable.com沒有使用它，因爲我的服務器提供商沒有安裝它。
git-lfs似乎是這個問題的一個很好的現代化解決方案。它將文件追蹤爲本地文本指針，並將它們存儲在外部大型文件存儲中。這有點像subrepo解決方案，但不需要進行過多的人工干預。
一方面，這使得您更加依賴互聯網訪問 - 如果您無法訪問外部文件存儲，您可能無法完全在分支之間切換。另一方面，這意味着您在克隆repo時不會下載每個二進制文件的全部歷史記錄。
代碼行數不說。 :) – 2011-04-22 14:15:27
例如，有些人更喜歡在新生產線上打開花括號，有些人使用大量的空行，有些在返回類型之後將他們的功能名稱放在行上，等等等等...... – 2011-04-22 16:07:15