在沒有版本控制的 Git 存儲庫中分發二進制文件的最新版本

Question

我正在 Git 中跟蹤一個游戲開發項目，其中有游戲需要運行的源代碼和已編譯的二進制文件。

目前，我的解決方案是使用 LFS 跟蹤源代碼和二進制文件，因為我希望能夠將它們分發給可能只想運行游戲的其他貢獻者（可能是程序員、關卡設計師、美工等） ，或編輯關卡或紋理，而無需強制他們在每次相關拉動時重建和重新編譯二進制文件。

然而，與 Git 上的大型二進制文件一樣，這會增加存儲庫的大小並實現多余的版本控制； 在這種情況下，任何二進制合並沖突都可以通過簡單地合並源代碼並重新構建來解決。

我已經搜索了很多，但我一直無法找到適合我的用例的特定解決方案。 最后，我的目標是：

1. 每個分支的最新編譯二進制文件（由 gitattributes 或類似的東西指定）分發給克隆或拉取存儲庫的任何人，而無需重新編譯代碼或級別。
2. 二進制文件的舊版本不會保存在 Git 中，當我已經對源文件進行版本控制時，存儲庫的大小會膨脹。
3. 這不需要大量的額外工作，比如創建一個新版本以在每次代碼更改時上傳二進制文件； 理想情況下，它發生在幕后，因此貢獻者可以像 LFS 一樣正常地與存儲庫交互。
4. 適用於 Windows 10 和 GitLab，具有最少的依賴性。

我已經收集了一些我可以為此采取的選項，盡管它們都不令人滿意。

• gitignoring 所有已編譯的二進制文件
  優點：根本不必擔心二進制文件。 推送源文件無后顧之憂。
  缺點：每當有人拉動時，他們需要記下發生了什么變化並重建受其影響的任何東西。 浪費大量時間，尤其是對於只想運行游戲或進行一些資產更改的非程序員而言。
• 使用 LFS 跟蹤所有已編譯的二進制文件
  優點：一切都非常干凈，二進制文件與其他文件一起保存在 repo 中，因此每個人都可以獲得一份副本。
  缺點：對生成的文件進行不必要的版本控制使存儲庫膨脹。
• 將編譯后的二進制文件存儲在單獨的 repo 中，並使用 git hooks 從中推/拉； 使用淺克隆或使用 GitLab API 卷曲
  優點：使二進制文件與主存儲庫隔離，並留在后台。 到目前為止，似乎是我最好的選擇。
  缺點：基本上只是將相同的問題推到另一個倉庫中，感覺就像重新發明輪子。
• git-annex ，我在類似問題中看到過
  優點：似乎應該是一個解決方案； 它的網站提到它如何用類似於 LFS 的指針替換某些文件，這聽起來很正確。
  缺點：似乎不是為 Windows 設計的。 抱怨損壞的文件系統。 文檔和教程似乎真的很少，我什么也想不通。
• git-fat ，我在類似問題中看到的另一個實用程序
  優點：根據自述文件看起來很有希望，雖然我真的不知道它在做什么。
  缺點：似乎需要一台服務器來托管文件，而我沒有。 看起來它也不是為 Windows 制作的。

我懷疑我是第一個遇到這個問題的人，我覺得我錯過了一些東西。 在 Git 協作環境中處理這樣的已編譯二進制文件的最簡單方法是什么？

Answer 1

Git 存儲庫不是為跟蹤二進制構建工件而設計的。 如您所見，這會使存儲庫膨脹並導致合並沖突。 您確實應該忽略任何構建工件並確保它們沒有被檢入您的存儲庫。

正如 LeGEC 在評論中建議的那樣，您需要一個發布服務器。 這可能是您維護的服務器（例如，帶有 HTTP 服務器的 VPS）或雲存儲桶。 如果您使用 CI 系統來構建和測試您的構建，有時這些系統會托管最新版本的構建工件； 例如，GitHub Actions 就是這樣做的。 還有更高級的工具，比如 Artifactory。

請注意，我所知道的所有主要托管服務提供商都支持在獲得一定數量的數據后對 Git LFS 收費，因此托管您自己的雲存儲桶可能比 Git LFS 更便宜（並且支持修剪更好）。

如果您最終將它們簽入存儲庫，您的托管服務提供商將會對您不滿意，因為存儲庫會變得越來越大，並且維護它會變得昂貴且緩慢，因此他們可能會要求您在某些時候停止這樣做觀點。