Arbeta med stora filer på din Git-lagringsplats

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Använd Git för källfiler, Azure Artifacts för beroenden och Git LFS för stora binära filer som ändras ofta. Om lagringsplatsen redan innehåller stora filer hjälper den här artikeln dig att bestämma vad du ska behålla i Git, vad du ska flytta ut och när du ska ta bort binärfiler från historiken.

Bestäm var varje fil ska lagras

Om du bestämmer vad du ska göra med filer som redan finns på en lagringsplats börjar du här:

  • Behåll källfiler, skript och textfiler i Git.
  • Flytta beroenden och återanvändbara paket till Azure Artifacts pakethantering.
  • Använd Git LFS för stora binära filer som ändras ofta och som inte lämpar sig för differensjämförelser.
  • Ta bort stora binärfiler från lagringsplatsens historik om de redan är incheckade och inte längre hör hemma där. Se Ta bort stora filer från en lagringsplats.

Om lagringsplatsen redan är stor granskar du lagringsplatsen och push-gränserna innan du väljer en lagringsmetod. Se Git-gränser för fil-, push- och sökvägsgränser som påverkar stora lagringsplatser.

Välj rätt lagringsalternativ för Git, pakethantering och Git LFS

Använd den här tabellen för att välja den bästa passformen.

Filtyp eller scenario Användning
Källkod, skript och textfiler Git
Beroenden och återanvändbara paket Azure Artifacts pakethantering
Stora binära filer som ändras ofta Git LFS
Azure DevOps Server Git LFS och Kerberos Se Kerberos-vägledningen i den här artikeln och den länkade artikeln i slutet

Git fungerar bäst för textbaserade källfiler och annat innehåll som ändras i små, läsbara steg.

Stora binärfiler passar inte för vanlig Git-lagring eftersom:

  • Git lagrar versionsskillnader effektivt för källkod, skript och textfiler.
  • Stora filer som ändras helt mellan versioner komprimeras inte eller diff bra.
  • Stora binära filer ökar tiderna för kloning, hämtning, förgrening och utcheckning.

Om du lägger till stora, oåtkomliga filer, till exempel binärfiler på lagringsplatsen, 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 filer hör hemma i Git?

Använd det enklaste alternativet som passar filtypen och hur ofta den ändras.

Behåll källkod i Git, inte beroenden

Använd Git för filer som teamet redigerar direkt. Håll beroenden borta från lagringsplatsen och leverera dem via pakethantering.

  • Placera källfiler i Git.
  • Lagra DLL:er, biblioteksfiler och andra beroenden utanför lagringsplatsen.
  • Använd pakethantering för att versionshantera och distribuera beroenden.

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.

Committa inte byggresultat

Använd Git som källa, inte skapa utdata eller testa artefakter.

  • Checka inte in binärfiler, loggar, spårningsutdata eller diagnostikdata.
  • Dela loggar och spåra information via spårning av arbetsobjekt eller gruppfildelning.

Lagra små binära filer i Git

Använd Endast Git för små binära filer när de ändras sällan.

  • Bra exempel är webbbilder, ikoner och andra små konsttillgångar.
  • Att behålla dessa filer i Git bevarar ett konsekvent arbetsflöde för teamet.

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 minskar den mindre binära filen förgreningsprestanda oftare än den stora binära filen.

Undvik stora, ofta uppdaterade binära tillgångar

Git kan inte effektivt lagra stora binärfiler eftersom dessa filer ofta ändras mellan versioner och vanligtvis redan är komprimerade.

  • Git lagrar det fullständiga innehållet i varje version.
  • Lagringsplatsens storlek växer med tiden.
  • Klona, förgrena, hämta och checka ut går långsammare.

Eftersom Git måste lagra det fullständiga innehållet i varje version hjälper deltifiering och komprimering inte mycket. När dessa filer ackumuleras blir lagringsplatsen större, förgrening blir långsammare och kloningstiderna ökar.

Strategier för stora binära källfiler

  • Lägg inte till komprimerade arkiv. Dekomprimera datafilerna och checka i stället in de jämförbara källfilerna.
  • Undvik att kommittera kompilerad kod och andra binära beroenden. Skapa dem eller tillhandahåll dem via pakethantering.
  • Lagra konfiguration och andra strukturerade data i diffable plain-text format, till exempel JSON.

Vad är Git Large File Storage (Git LFS)?

Använd Git Large File Storage (LFS) för källfiler som ofta ändras och skiljer sig avsevärt mellan olika versioner.

Git LFS:

  • Lagrar pekare till stora filer på lagringsplatsen i stället för det fullständiga filinnehållet.
  • Lagrar det binära innehållet i separat fjärrlagring.
  • Laddar ned rätt version när du klonar eller växlar grenar.
  • Behåller ditt vanliga Git-arbetsflöde för stora binärfiler utan att flytta hela filinnehållet genom varje kloning och grenändring.

Fördelar med Git LFS

Git LFS behåller Git-arbetsflödet samtidigt som stort filinnehåll flyttas från huvudplatsen.

  • Ditt team kan fortsätta att använda samma Git-arbetsflöde från slutpunkt till slutpunkt.
  • Stora filer håller sig borta från huvudlagringsplatsens historik, vilket hjälper till att hålla lagringsplatsen hanterbar.
  • Fillåsning stöder delat arbete med stora, oförstörbara tillgångar som videor, ljud och spelkartor.

Azure DevOps Services har fullt stöd för Git LFS och erbjuder det kostnadsfritt. Om du vill använda LFS installerar du Git LFS-klienten, konfigurerar spårning för de filer som du vill lagra i LFS och push-överför sedan ändringarna till Azure-lagringsplatser.

Mer Azure DevOps Server och Kerberos-specifik vägledning finns i Kerberos och Git LFS.

Git LFS-begränsningar

Git LFS har fortfarande några kompromisser att planera för:

  • Varje Git-klient måste installera Git LFS-klienten och förstå dess spårningskonfiguration.
  • Om klienten inte är korrekt installerad eller konfigurerad hämtar kloner pekardata i stället för den binära filen.
  • Git kan inte slå samman olika versioner av en binär fil, så gruppmedlemmar måste fortfarande samordna ändringar.
  • Git LFS tillhandahåller fillåsning, men användarna måste fortfarande hämta den senaste kopian innan de börjar arbeta.
  • Azure-lagringsplatser stöder inte Secure Shell (SSH) för lagringsplatser med Git LFS-spårade filer.
  • Att dra en binär fil in i webbgränssnittet committerar den binära filen till repot, inte LFS-pekaren.
  • Stora uppladdningar kan begränsas av tillgängligt ledigt utrymme, aktuell arbetsbelastning och uppladdningsgränsen på en timme.

Git LFS-filformat

Filen som du skriver till lagringsplatsen 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

Anmärkning

Planera för Azure DevOps Server och Kerberos

Om du använder Azure DevOps Server- och Windows-autentisering ska du planera för Kerberos när du använder Git LFS. Git LFS 2.10.0 och senare stöder Kerberos-autentisering.

Om du behöver uppdatera äldre Azure DevOps Server vägledning börjar du med Kerberos och Git LFS och den länkade Azure DevOps Server autentiseringsvägledning.

Relaterat innehåll

  • Last updated on