Dela via

Hantera och lagra stora filer i Git

  • Artikel

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

Git hjälper till att hålla källkodens fotavtryck litet eftersom skillnaderna mellan versioner enkelt plockas ut och koden enkelt komprimeras. Stora filer som inte komprimeras bra och som ändras helt mellan versioner (till exempel binärfiler) medför problem när de lagras i git-lagringsplatserna. Gits snabba prestanda kommer från dess förmåga att adressera och växla till alla versioner av en fil från dess lokala lagring.

Om du har stora, oåtkomliga filer på lagringsplatsen (till exempel binärfiler) behåller du en fullständig kopia av filerna på lagringsplatsen varje gång du genomför en ändring av dem. Om det finns många versioner av dessa filer på lagringsplatsen ökar de avsevärt tiden för att checka ut, förgrena, hämta och klona koden.

Vilka typer av filer ska du lagra i Git?

Checka in källkod, inte beroenden

Eftersom ditt team arbetar med redigeringsprogram och verktyg för att skapa och uppdatera filer bör du placera dessa filer i Git så att ditt team kan dra nytta av fördelarna med Git-arbetsflödet. Checka inte in andra typer av filer i lagringsplatsen: till exempel DLL:er, biblioteksfiler och andra beroenden som ditt team inte skapar, men koden är beroende av. Leverera dessa filer via pakethantering till dina system.

Pakethantering paketar dina beroenden och installerar filerna i systemet när du distribuerar paketet. Paket är versionshanterade för att säkerställa att kod som testas i en miljö körs på samma sätt i en annan miljö, förutsatt att miljöerna har samma installerade paket.

Checka inte in utdata

Checka inte in binärfiler, loggar, spårningsutdata eller diagnostikdata från dina versioner och tester. Det här är utdata från din kod, inte själva källkoden. Dela loggar och spårningsinformation med ditt team via verktyg för spårning av arbetsobjekt eller genom fildelning i team.

Lagra små, sällan uppdaterade binära källor i Git

Binära källfiler som uppdateras sällan har relativt få versioner incheckade. De tar inte upp mycket utrymme om filstorleken är liten. Bilder för webben, ikoner och andra mindre konsttillgångar kan ingå i den här kategorin. Det är bättre att lagra dessa filer i Git med resten av källan så att ditt team kan använda ett konsekvent arbetsflöde.

Viktigt!

Även små binärfiler kan orsaka problem om de uppdateras ofta. Till exempel använder 100 ändringar i en binär fil på 100 KB så mycket lagringsutrymme som 10 ändringar i en binär fil på 1 MB. På grund av uppdateringsfrekvensen kommer den mindre binärfilen att göra förgreningsprestandan långsammare än den stora binära.

Checka inte in stora, ofta uppdaterade binära tillgångar

Git hanterar en huvudversion av en fil och lagrar sedan endast skillnaderna från den versionen, i en process som kallas deltifiering. Med deltifiering och filkomprimering kan Git lagra hela kodhistoriken på din lokala lagringsplats. Stora binärfiler ändras vanligtvis helt mellan versioner och komprimeras ofta redan. Dessa filer är svåra för Git att hantera eftersom skillnaderna mellan versioner är stora.

Git måste lagra hela innehållet i varje version av filen och har svårt att spara utrymme genom deltifiering och komprimering. Om du lagrar de fullständiga versionerna av dessa filer ökar lagringsplatsens storlek med tiden. Den ökade lagringsplatsens storlek minskar förgreningsprestandan, ökar kloningstiderna och utökar lagringskraven.

Strategier för att arbeta med stora binära källfiler

  • Checka inte in komprimerade dataarkiv. Det är bättre att avkomprimera filerna och checka in de olika källorna. Låt Git hantera komprimering av data i lagringsplatsen.
  • Undvik att checka in kompilerad kod och andra binära beroenden. Checka in källan och skapa beroendena, eller använd en pakethanteringslösning för att version och ange dessa filer i systemet.
  • Lagra konfiguration och andra strukturerade data i diffable plain-text format, till exempel JSON.

Vad är Git LFS?

När du har källfiler med stora skillnader mellan versioner och frekventa uppdateringar kan du använda Git Large File Storage (LFS) för att hantera dessa filtyper. Git LFS är ett tillägg till Git som tillhandahåller data som beskriver de stora filerna i en incheckning till lagringsplatsen. Den lagrar innehållet i den binära filen i separat fjärrlagring.

När du klonar och byter förgrening på din lagringsplats hämtar Git LFS rätt version från fjärrlagringsplatsen. Dina lokala utvecklingsverktyg fungerar transparent med filerna som om de checkades in direkt till lagringsplatsen.

Förmåner

En fördel med Git LFS är att ditt team kan använda det välbekanta Git-arbetsflödet från slutpunkt till slutpunkt oavsett vilka filer ditt team skapar. LFS hanterar stora filer för att förhindra att de påverkar den övergripande lagringsplatsen negativt. Från och med version 2.0 har Git LFS dessutom stöd för fillåsning som gör det enklare för ditt team att arbeta med stora, oförstörbara tillgångar som till exempel videor, ljud och spelkartor.

Git LFS stöds fullt ut och är kostnadsfritt i Azure DevOps Services. Om du vill använda LFS med Visual Studio behöver du Visual Studio 2015 Update 2 eller senare. Följ bara anvisningarna för att installera klienten, konfigurera LFS-spårning för filer på din lokala lagringsplats och skicka sedan ändringarna till Azure Repos.

Begränsningar

Git LFS har några nackdelar som du bör överväga innan du antar det:

  • Varje Git-klient som ditt team använder måste installera Git LFS-klienten och förstå dess spårningskonfiguration.
  • Om Git LFS-klienten inte har installerats och konfigurerats på rätt sätt ser du inte de binära filerna som checkas in via Git LFS när du klonar din lagringsplats. Git laddar ned data som beskriver den stora filen (vilket är vad Git LFS checkar in på lagringsplatsen) och inte den binära filen. Om du checkar in stora binära filer utan att Git LFS-klienten är installerad så skickas den binära filen till din lagringsplats.
  • Git kan inte slå ihop ändringarna från två olika versioner av en binär fil även om båda versionerna har en gemensam överordnad fil. Om två personer arbetar med samma fil samtidigt måste de arbeta tillsammans och stämma av sina ändringar så att de inte råkar skriva över varandras arbete. Git LFS har en fillåsningsfunktion för just detta. Användarna måste ändå vara noga med att alltid hämta den senaste kopian av en binär resurs innan de börjar arbeta.
  • Azure Repos stöder för närvarande inte användning av Secure Shell (SSH) i lagringsplatser med Git LFS-spårade filer.
  • Om en användare drar en binär fil via webbgränssnittet till en lagringsplats som har konfigurerats för Git LFS, checkas binärfilen in på lagringsplatsen – inte pekarna som skulle checkas in via Git LFS-klienten.
  • Även om det inte finns någon strikt begränsning av filstorleken kan serverns tillgängliga lediga utrymme och aktuella arbetsbelastning begränsa prestanda och funktioner.
  • Tidsgränsen för en filuppladdning är en timme.

File format

Filen som skrivits till din lagringsplats för en Git LFS-spårad fil har några rader med ett nyckel/värde-par på varje rad:

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

Kommentar

GitHub-URL:en som ingår för versionsvärdet definierar bara filtypen LFS-pekare. Det är inte en länk till din binära fil.

Kända problem

Om du använder en version av LFS tidigare än 2.4.0 med Azure DevOps Server krävs ett extra installationssteg för att autentisera via NTLM i stället för Kerberos. Det här steget är inte längre nödvändigt från och med LFS 2.4.0, och vi rekommenderar starkt att du uppgraderar.