Nagyméretű fájlok kezelése és tárolása a Gitben

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

A Git segít kicsiben tartani a forráskód lábnyomát, mivel a verziók közötti különbségek könnyen kiválogathatók, a kód pedig könnyen tömöríthető. A nagy méretű fájlok, amelyek nem tömörítik megfelelően a tömörítést, és amelyek teljesen megváltoznak a verziók (például bináris fájlok) között, problémákat okoznak a Git-adattárakban való tároláskor. A Git gyors teljesítménye abból adódik, hogy képes a helyi tárolóból származó fájl minden verziójára címeket kezelni és váltani.

Ha nagy, nem közömbös fájlokkal rendelkezik az adattárban (például bináris fájlok), a fájlok teljes másolatát minden alkalommal megőrzi az adattárban, amikor módosítást hajt végre rajtuk. Ha ezeknek a fájloknak számos verziója létezik az adattárban, jelentősen megnövelik a kód kivételének, ágának, beolvasásának és klónozásának idejét.

Milyen típusú fájlokat tároljon a Gitben?

Forráskód véglegesítése, nem függőségek

Mivel a csapat szerkesztőkkel és eszközökkel dolgozik a fájlok létrehozásán és frissítésén, ezeket a fájlokat a Gitbe kell helyeznie, hogy a csapata élvezhesse a Git munkafolyamatának előnyeit. Ne véglegesítsen más típusú fájlokat az adattárba: például DLL-eket, tárfájlokat és más függőségeket, amelyeket a csapat nem hoz létre, de a kód függ. Ezeket a fájlokat csomagkezeléssel kézbesítheti a rendszereknek.

A csomagkezelés kötegeli a függőségeket, és telepíti a fájlokat a rendszerre a csomag üzembe helyezésekor. A csomagok verziószáma biztosítja, hogy az egyik környezetben tesztelt kód ugyanúgy fusson egy másik környezetben, amíg a környezetek ugyanazokat a telepített csomagokat futtatják.

Kimenetek véglegesítése mellőzése

Ne véglegesítse a bináris fájlokat, naplókat, nyomkövetési kimenetet vagy diagnosztikai adatokat a buildekből és tesztekből. Ezek a kód kimenetei, nem maga a forráskód. Naplókat és nyomkövetési információkat oszthat meg a csapatával a munkaelem-követési eszközökkel vagy a csoportfájl-megosztással.

Kis méretű, ritkán frissített bináris források tárolása a Gitben

A ritkán frissített bináris forrásfájlok viszonylag kevés verziót véglegesítenek. Nem sok helyet foglalnak el, ha a fájlméretük kicsi. A webes képek, ikonok és más kisebb művészeti objektumok ebbe a kategóriába tartozhatnak. Érdemes ezeket a fájlokat a Gitben tárolni a forrás többi részével, hogy a csapat konzisztens munkafolyamatot használjon.

Fontos

Még a kis bináris fájlok is problémákat okozhatnak, ha gyakran frissülnek. Egy 100 KB-os bináris fájl 100 módosítása például annyi tárhelyet használ, mint 10 módosítás egy 1 MB-os bináris fájlban. A frissítések gyakorisága miatt a kisebb binárisok gyakrabban lassítják az elágaztatási teljesítményt, mint a nagy bináris.

Ne véglegesítsen nagy, gyakran frissített bináris objektumokat

A Git egy fájl egy fő verzióját kezeli, majd csak az adott verzió eltéréseit tárolja egy deltification nevű folyamatban. A deltification és a fájltömörítés lehetővé teszi a Git számára a teljes kódelőzmények tárolását a helyi adattárban. A nagy bináris fájlok általában teljesen változnak a verziók között, és gyakran már tömörítve vannak. Ezek a fájlok nehezen kezelhetők a Git számára, mert a verziók közötti különbségek nagyok.

A Gitnek a fájl minden egyes verziójának teljes tartalmát tárolnia kell, és nehézséget okoz a helytakarékosság a deltification és a tömörítés révén. A fájlok teljes verziójának tárolása miatt az adattár mérete idővel megnő. A megnövekedett adattárméret csökkenti az elágaztatási teljesítményt, növeli a klónozási időt, és kibővíti a tárolási követelményeket.

Stratégiák nagy bináris forrásfájlok használatához

• Ne véglegesítse a tömörített adatarchívumokat. Jobb, ha kibontja a fájlokat, és véglegesíti a közömbös forrásokat. Hagyja, hogy a Git kezelje az adattárban lévő adatok tömörítését.
• Kerülje a lefordított kód és más bináris függőségek véglegesítését. Véglegesítse a forrást, és hozza létre a függőségeket, vagy használjon csomagkezelési megoldást a fájlok verziószámának és a rendszernek való ellátásához.
• A konfigurációt és más strukturált adatokat közömbös, egyszerű szöveges formátumban tárolja, például JSON formátumban.

Mi az a Git LFS?

Ha olyan forrásfájlokkal rendelkezik, amelyekben nagy különbségek vannak a verziók és a gyakori frissítések között, a Git Large File Storage (LFS) használatával kezelheti ezeket a fájltípusokat. A Git LFS a Git bővítménye, amely az adattárhoz tartozó véglegesítés nagy fájljait leíró adatokat nyújt. A bináris fájl tartalmát külön távoli tárolóba tárolja.

Amikor ágakat klónoz és ágak között vált az adattárban, a Git LFS a megfelelő verziót tölti le erről a távoli tárolóról. A helyi fejlesztői eszközök transzparens módon működnek a fájlokkal, mintha közvetlenül az adattárhoz lettek volna véglegesítettek.

Juttatások

A Git LFS egyik előnye, hogy csapata a csapat által létrehozott fájloktól függetlenül használhatja a jól ismert, végpontok közötti Git-munkafolyamatot. Az LFS kezeli a nagy fájlokat, hogy ne befolyásolják hátrányosan a teljes adattárat. Emellett a Git LFS a 2.0-s verziótól kezdve támogatja a fájlok zárolását, hogy csapata különböző nagy méretű adategységekkel, például videókkal, hangfájlokkal és játéktérképekkel is dolgozhasson, amelyeknek a változásait nem lehet megjeleníteni.

A Git LFS teljes mértékben támogatott és ingyenes az Azure DevOps Servicesben. Az LFS Visual Studióval való használatához a Visual Studio 2015 2. vagy újabb frissítésére van szükség. Egyszerűen kövesse az utasításokat az ügyfél telepítéséhez, állítsa be a helyi adattárban lévő fájlok LFS-nyomon követését, majd küldje el a módosításokat az Azure-adattárakba.

Korlátozások

A Git LFS-nek vannak hátrányai, amelyeket érdemes megfontolnia annak bevezetése előtt:

• A csapat által használt összes Git-ügyfélnek telepítenie kell a Git LFS-ügyfelet, és ismernie kell annak nyomkövetési konfigurációját.
• Ha a Git LFS-ügyfél nincs megfelelően telepítve és konfigurálva, az adattár klónozásakor nem fogja látni a Git LFS használatával véglegesített bináris fájlokat. A Git letölti a nagy fájlt leíró adatokat (ez az, amit a Git LFS véglegesít az adattárban), és nem a bináris fájlt. Ha nagy méretű bináris fájlokat véglegesít a Git LFS-ügyfél telepítése nélkül, a bináris fájl le lesz küldve az adattárba.
• A Git akkor sem tudja egyesíteni a bináris fájlok két különböző verziójának módosításait, ha a két verzió közös szülővel rendelkezik. Ha két személy egyszerre dolgozik ugyanazon a fájlon, együtt kell működniük a módosításaik egyeztetéséhez, hogy elkerüljék egymás munkájának felülírását. A Git LFS segítségként fájlzárolást nyújt. A felhasználóknak továbbra is ügyelniük kell arra, hogy a munka megkezdése előtt mindig lekérjék a bináris objektum legújabb másolatát.
• Az Azure Repos jelenleg nem támogatja a Secure Shell (SSH) használatát a Git LFS által követett fájlokkal rendelkező adattárakban.
• Ha egy felhasználó a webes felületen keresztül húz egy bináris fájlt egy Git LFS-hez konfigurált adattárba, a bináris a tárházban lesz véglegesített – nem a Git LFS-ügyfélen keresztül véglegesítendő mutatókra.
• Bár nincs szigorú fájlméret-korlátozás, a kiszolgáló rendelkezésre álló szabad területe és a jelenlegi számítási feladat korlátozhatja a teljesítményt és a funkcionalitást.
• Egy fájlfeltöltésre vonatkozó időkorlát egy óra.

Fájlformátum

A Git LFS által követett fájl adattárába írt fájl néhány sorból áll, mindegyik sorban egy kulcs/érték pár található:

version https://git-lfs.github.com/spec/v1
oid a747cfbbef63fc0a3f5ffca332ae486ee7bf77c1d1b9b2de02e261ef97d085fe
size 4923023

Feljegyzés

A verzióértékhez tartozó GitHub URL-cím csak az LFS mutatófájl típusát határozza meg. Ez nem a bináris fájlra mutató hivatkozás.

Ismert problémák

Ha az LFS 2.4.0-nál korábbi verzióját használja az Azure DevOps Serverrel, a Kerberos helyett az NTLM-en keresztüli hitelesítéshez további beállítási lépés szükséges. Ez a lépés már nem szükséges az LFS 2.4.0-s verziójától, ezért javasoljuk, hogy frissítsen.