本篇內(nèi)容主要講解“Gitee存儲庫體積控制的方法”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“Gitee存儲庫體積控制的方法”吧!

網(wǎng)站建設(shè)公司,為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計及定制網(wǎng)站建設(shè)服務(wù),專注于企業(yè)網(wǎng)站設(shè)計,高端網(wǎng)頁制作,對紙箱等多個行業(yè)擁有豐富的網(wǎng)站建設(shè)經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。專業(yè)網(wǎng)站設(shè)計,網(wǎng)站優(yōu)化推廣哪家好,專業(yè)營銷推廣優(yōu)化,H5建站,響應(yīng)式網(wǎng)站。

前言

作為全球 Top2 的代碼托管平臺之一，Gitee 擁有350W 用戶和 600W 存儲庫，海量的存儲庫對 Gitee 的硬件設(shè)施提出了更高的要求，以 600W 存儲庫為例，如果按照平均 1GB 的大小磁盤體積，這些存儲庫將需要總共 5860 TB 的空間，按照 Gitee 每臺存儲磁盤 14TB，則需要 419 臺存儲設(shè)備。實(shí)際上在 Gitee 中，絕大多數(shù)存儲庫的體積都小于 100 M，超過 100 M 的存儲庫通常都是未合理使用 git。盡管如此，Gitee 仍然需要投入大量的存儲設(shè)備來支撐用戶的接入。為了能夠讓更多的人能夠免費(fèi)使用 Gitee，我們迫不得已只能限制大存儲庫的訪問。近期，Gitee 存儲庫路由架構(gòu)改造第一階段已經(jīng)到了收尾階段，在此期間，我們將陸續(xù)將服務(wù)端的鉤子切換到 GNK (Gitee Native Hook)，GNK 基于 C++ 編寫，使用了 Git 環(huán)境隔離等高級特定，意味著大文件檢測和存儲庫體積檢測不會再有漏網(wǎng)之魚。一些用戶的存儲庫體積已經(jīng)超過了 Gitee 配額限制，而之前的鉤子檢測存在缺陷，無法實(shí)時攔截大存儲庫和大文件，當(dāng)切換到 GNK 后，這些用戶修改他們的存儲庫卻無法推送到 Gitee，這讓他們產(chǎn)生了困擾，本文就這一困擾解答若干問題。當(dāng)然如果用戶有其他問題也可以在本文下留言。

Gitee 套餐信息

Gitee 分為普通用戶，和企業(yè)用戶，個人的套餐實(shí)際和企業(yè)免費(fèi)版一致，最新的套餐信息 如下：

大存儲庫的產(chǎn)生

Git 是基于文件快照的，但并不是所有時候都存儲快照，當(dāng)對象被打包到 .pack文件中時，則有可能存儲對象的差異，即 OBJ_OFS_DELTA/OBJ_REF_DELTA。這種機(jī)制使得在文件大小不變的情況下，每次修改文件都會導(dǎo)致存儲庫體積按大于文件壓縮后體積增長，以一個 Zip 壓縮文件為例，每次修改后大小為 50 MB，提交 20次便能夠超過 1000 MB。當(dāng)用戶將項(xiàng)目中的構(gòu)建文件諸如 .exe,.pdb,.so,.jar 或者依賴文件/文件夾 node_modules,packages 以及資源文件 .psd,.raw,.avi,.jpg 添加到版本控制中后，很容易使得存儲庫體積超出限制。

大文件除了容易讓存儲庫超出限制，而且也會降低用戶拉取代碼的體驗(yàn)，git 在處理二進(jìn)制文件時需要花費(fèi)更多的 CPU。

GNK 的攔截

隨著存儲服務(wù)器陸續(xù)切換到 GNK，超出配額的報告也可能會更多。GNK 的攔截是實(shí)時的，即用戶將代碼推送到服務(wù)器后，git-receive-pack 將調(diào)用 GNK 中的 pre-receive 鉤子，這個鉤子將統(tǒng)計存儲庫的 objects 目錄，將所有文件和目錄所占用的磁盤空間大小累加就獲得了存儲庫的體積，這和 du -sh 機(jī)制一致，特別的，我們這里說的存儲庫體積包含其附帶的 wiki 存儲庫的目錄，這也是為了避免個別用戶使用 wiki 存儲大文件。

GNK 目前會給大存儲庫推送提供三次機(jī)會，如果三次讀沒有減小存儲庫體積，則便無法繼續(xù)修改遠(yuǎn)程存儲庫，以 Linux 內(nèi)核 1.4 G 為例，如下所示：

第三次時如果存儲庫體積依然超出限制，則會告知用戶，已經(jīng)耗盡所有機(jī)會，無法重試。

無法嘗試時，輸出如下：

GNK 還會攔截用戶推送的大文件，但已經(jīng)存在于存儲庫的大文件，GNK 不會去檢測。基于 Git 環(huán)境隔離機(jī)制實(shí)現(xiàn)的 GNK，攔截大文件不會像之前一樣反復(fù)推送大文件失敗導(dǎo)致存儲庫體積變大，環(huán)境隔離目錄在 pre-receive 執(zhí)行失敗后會被刪除。

存儲庫的精簡方案

在開發(fā)的時候，我們可以使用包管理工具管理項(xiàng)目依賴，比如 dotnet core 使用 NuGet，Java 使用 Maven，完全沒有必要將依賴二進(jìn)制納入版本控制。

如果不慎將大文件納入了版本控制中，可以去訪問 Gitee 幫助：倉庫體積過大，如何減小？。在修改本地存儲庫歷史記錄后，通過 git push -f 的方式推送到 Gitee，然后在項(xiàng)目配置頁面運(yùn)行 Git GC 待 GC 運(yùn)行后，通常能夠發(fā)現(xiàn)存儲庫體積變小。注意：當(dāng)修改本地存儲庫歷史后強(qiáng)制推送到遠(yuǎn)程服務(wù)器，在運(yùn)行 GC 之前，可以觀察到存儲庫的體積顯著增大，只有在運(yùn)行 git gc 后，才可能會使存儲庫體積變小。

當(dāng)然你還可以使用 git-sizer 查看存儲庫的占用細(xì)節(jié)，或者使用新的 git-filter-repo 去修改存儲庫歷史記錄。git-filter-repo 已經(jīng)成為了 Git 的官方推薦。

如果項(xiàng)目使用 PR 機(jī)制參與協(xié)作開發(fā)，強(qiáng)制推送后運(yùn)行 git gc 可能不會減小存儲庫的體積（這是因?yàn)榇鎯煨枰褂脙?nèi)部引用保持 PR 相應(yīng)的 commit 的可用性，不被 GC），這個時候用戶可以升級套餐，獲得更大的存儲庫容量，或者在 Gitee 上新建一個空存儲庫，將修改歷史記錄的存儲庫推送到新的存儲庫。使用新的存儲庫即可。

一些大文件無法用版本控制可以將其使用 Git LFS 管理，用戶需要使用 Git LFS 可以查看 Gitee LFS。

對于一些用戶由于疏忽已經(jīng)用完重試次數(shù)則可以聯(lián)系官方團(tuán)隊(duì)重置重試次數(shù)

到此，相信大家對“Gitee存儲庫體積控制的方法”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！