我們在 git 中有一個檔案，它大約 1GB 大。但是，此檔案是在引擎中生成的，并且需要數小時的完整 CPU 使用時間才能生成。因此，我們希望將其推送到 git 并對其進行維護。但是，它不需要經常推送。事實上，我們幾乎從不想推送這個檔案，除非我們是為分發而構建的。
現在有幾次，有人不小心把這個檔案推了上去，它使用了大量的 LFS 帶寬和存盤空間。我希望能夠添加一個 git pre-commit 鉤子以確保該檔案被強制添加到提交中，或者只是某種方式來仔細檢查檔案的添加。
我從來沒有制作過鉤子腳本，有什么方法可以用預提交鉤子完成這個功能嗎？我正在努力尋找有關創建這些腳本以及我可以訪問哪些屬性的常規檔案。另外，如果有更簡單的方法來完成我想要的，那將非常感激！
uj5u.com熱心網友回復：
你不能用預提交鉤子真正做到這一點。請記住，每個Git提交都包含每個檔案（它包含），并且由于您當前簽出提交（其他一些當該檔案在 commit 中不存在時，哈希 ID 比) 中存在某些檔案。git checkoutgit switchHGHH
因此，大檔案要么在每次提交中，要么不在提交中：沒有真正的中間立場。Git 確實通過重新使用相同內容的檔案來優化事情，所以如果 100 次提交包含大檔案的版本 1，而接下來的 100 次提交包含大檔案的版本 2，那么實際上只有兩個大檔案的副本在存盤庫中，每個共享 100 個提交。
發送重新使用現有大檔案的新提交的 Agit push不會重新發送大檔案，因為接收 Git 將E在您的 Git 發送新提交時宣布它具有現有提交N，然后您的 Git 將看到大檔案副本N與大檔案副本匹配E，因此不需要使用新提交發送檔案N。所以聽起來你真正想要的是——雖然你沒有意識到——是一種檢測是否git push會發送一個新的不同的大檔案的方法，而接收端的 Git 目前缺乏這種方法。
您無法完美地檢測到這一點，但您可以在pre-push鉤子（而不是 pre-commit 鉤子）中輕松獲得不錯的效果。Git 在您的 Git 聯系他們的 Git 后運行 pre-push 鉤子，并找出哈希 ID 與您要求他們更新的任何現有 ref 搭配。pre-push 鉤子可以從其標準輸入中讀取您的 Git 建議發送到其 Git 的 refs 和哈希 ID 的完整串列，以及它們在您的 Git 建議更新的任何名稱下具有的哈希 ID。
使用此資訊，您可以看到，例如，您的 Git 提議向他們的 Git 發送可以從develop帶有 hash ID的分支提示訪問的提交a123456...。此時，他們有一個帶有 hash ID 的提交作為他們 的分支提示。在您自己的存盤庫中查找此提交，您會發現它確實包含大檔案，其內容的哈希 ID 為，并且在您自己的存盤庫中的所有提交中，它們都包含具有相同哈希 ID 的大檔案：在這種情況下，您不會發送大檔案的新副本。或者，也許您沒有，或者有一個大檔案，其 blob 散列但是developb976543...b976543deadcab...b976543..a1234567b976543b976543deadcab...a123456...將發送帶有散列內容的大檔案feeddad...。所以這次你的 Git 可能會發送大檔案，你可以強制用戶，例如，設定一個環境變數I_REALLY_MEANT_TO_DO_THAT=yes。
整個系統非常笨拙，據我所知，沒有人會這樣做。相反，大檔案被視為“構建資產”并存盤在存盤庫之外，以及告訴您構建資產的此特定副本是否適合您的構建的資訊。您首先檢查驗證資訊：如果正確，則使用預構建的資產，如果不正確，則花時間構建它（然后也可選擇將其交付給資產服務器）。
轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/435165.html