Share via

Grote bestanden beheren en opslaan in Git

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Git helpt de footprint van uw broncode klein te houden, omdat de verschillen tussen versies eenvoudig worden gekozen en code eenvoudig wordt gecomprimeerd. Grote bestanden die niet goed worden gecomprimeerd en die volledig worden gewijzigd tussen versies (zoals binaire bestanden) hebben problemen wanneer ze worden opgeslagen in uw Git-opslagplaatsen. De snelle prestaties van Git zijn afkomstig van de mogelijkheid om vanuit de lokale opslag over te schakelen naar alle versies van een bestand.

Als u grote, onherstelbare bestanden in uw opslagplaats (zoals binaire bestanden) hebt, behoudt u elke keer dat u een wijziging doorvoert een volledige kopie van die bestanden in uw opslagplaats. Als er veel versies van deze bestanden in uw opslagplaats aanwezig zijn, nemen ze de tijd voor uitchecken, vertakkingen, ophalen en klonen van uw code aanzienlijk uit.

Welke soorten bestanden moet u opslaan in Git?

Broncode doorvoeren, niet afhankelijkheden

Als uw team werkt met editors en hulpprogramma's om bestanden te maken en bij te werken, moet u deze bestanden in Git plaatsen zodat uw team kan profiteren van de voordelen van de werkstroom van Git. Voer geen andere typen bestanden door in uw opslagplaats: bijvoorbeeld DLL's, bibliotheekbestanden en andere afhankelijkheden die uw team niet maakt, maar uw code is afhankelijk van. Lever deze bestanden via pakketbeheer aan uw systemen.

Pakketbeheer bundelt uw afhankelijkheden en installeert de bestanden op uw systeem wanneer u het pakket implementeert. Pakketten zijn versiebeheer om ervoor te zorgen dat code die in de ene omgeving is getest, hetzelfde wordt uitgevoerd in een andere omgeving, zolang de omgevingen dezelfde geïnstalleerde pakketten hebben.

Uitvoer niet doorvoeren

Voer de binaire bestanden, logboeken, traceringsuitvoer of diagnostische gegevens van uw builds en tests niet door. Dit zijn uitvoer van uw code, niet de broncode zelf. Deel logboeken en traceringsgegevens met uw team via hulpprogramma's voor het bijhouden van werkitems of via het delen van teambestanden.

Kleine, onregelmatig bijgewerkte binaire bronnen opslaan in Git

Binaire bronbestanden die niet vaak worden bijgewerkt, hebben relatief weinig versies doorgevoerd. Ze nemen niet veel ruimte in beslag als hun bestandsgrootte klein is. Afbeeldingen voor het web, pictogrammen en andere kleinere kunstassets kunnen in deze categorie vallen. Het is beter om deze bestanden op te slaan in Git met de rest van uw bron, zodat uw team een consistente werkstroom kan gebruiken.

Belangrijk

Zelfs kleine binaire bestanden kunnen problemen veroorzaken als ze vaak worden bijgewerkt. 100 wijzigingen in een binair bestand van 100 kB gebruiken bijvoorbeeld zoveel opslagruimte als 10 wijzigingen in een binair bestand van 1 MB. Vanwege de frequentie van updates vertraagt het kleinere binaire bestand de vertakkingsprestaties vaker dan het grote binaire bestand.

Grote, regelmatig bijgewerkte binaire assets niet doorvoeren

Git beheert één hoofdversie van een bestand en slaat vervolgens alleen de verschillen van die versie op, in een proces dat deltification wordt genoemd. Met deltification en bestandscompressie kan Git uw volledige codegeschiedenis opslaan in uw lokale opslagplaats. Grote binaire bestanden veranderen meestal volledig tussen versies en worden vaak al gecomprimeerd. Deze bestanden zijn moeilijk te beheren door Git omdat de verschillen tussen versies groot zijn.

Git moet de volledige inhoud van elke versie van het bestand opslaan en heeft moeite om ruimte te besparen door middel van deltificatie en compressie. Door de volledige versies van deze bestanden op te slaan, neemt de grootte van de opslagplaats in de loop van de tijd toe. De grotere grootte van de opslagplaats vermindert de vertakkingsprestaties, verhoogt de kloontijden en breidt de opslagvereisten uit.

Strategieën voor het werken met grote binaire bronbestanden

  • Voer geen gecomprimeerde archieven met gegevens door. Het is beter om de bestanden op te heffen en de verschillende bronnen door te voeren. Laat Git de gegevens in uw opslagplaats comprimeren.
  • Vermijd het doorvoeren van gecompileerde code en andere binaire afhankelijkheden. Voer de bron door en bouw de afhankelijkheden, of gebruik een oplossing voor pakketbeheer om deze bestanden te versieren en op te geven aan uw systeem.
  • Sla configuratie en andere gestructureerde gegevens op in diffable indelingen voor tekst zonder opmaak, zoals JSON.

Wat is Git LFS?

Wanneer u bronbestanden hebt met grote verschillen tussen versies en frequente updates, kunt u Git Large File Storage (LFS) gebruiken om deze bestandstypen te beheren. Git LFS is een uitbreiding op Git die gegevens biedt die de grote bestanden in een doorvoer naar uw opslagplaats beschrijven. De inhoud van het binaire bestand wordt opgeslagen in afzonderlijke externe opslag.

Wanneer u vertakkingen in uw opslagplaats kloont en overschakelt, downloadt Git LFS de correcte versie van die externe opslag. Uw lokale ontwikkelhulpprogramma's werken transparant met de bestanden alsof ze rechtstreeks zijn doorgevoerd in uw opslagplaats.

Vergoedingen

Een voordeel van Git LFS is dat uw team de vertrouwde end-to-end Git-werkstroom kan gebruiken, ongeacht de bestanden die uw team maakt. LFS verwerkt grote bestanden om te voorkomen dat ze de algehele opslagplaats nadelig beïnvloeden. Daarnaast ondersteunt Git LFS vanaf versie 2.0 bestandsvergrendeling om uw team te helpen bij het werken aan grote, onwerkbare assets, zoals video's, geluiden en gamekaarten.

Git LFS wordt volledig ondersteund en gratis in Azure DevOps Services. Als u LFS wilt gebruiken met Visual Studio, hebt u Visual Studio 2015 Update 2 of hoger nodig. Volg de instructies om de client te installeren, LFS-tracering in te stellen voor bestanden in uw lokale opslagplaats en vervolgens uw wijzigingen naar Azure-opslagplaatsen te pushen.

Beperkingen

Git LFS heeft enkele nadelen die u moet overwegen voordat u het gaat gebruiken:

  • Elke Git-client die uw team gebruikt, moet de Git LFS-client installeren en de traceringsconfiguratie begrijpen.
  • Als de Git LFS-client niet correct is geïnstalleerd en geconfigureerd, ziet u de binaire bestanden die zijn doorgevoerd via Git LFS niet wanneer u uw opslagplaats kloont. Git downloadt de gegevens die het grote bestand beschrijven (wat git LFS doorvoert naar de opslagplaats) en niet het binaire bestand. Als u grote binaire bestanden doorvoert zonder dat de Git LFS-client is geïnstalleerd, wordt het binaire bestand naar uw opslagplaats gepusht.
  • Git kan de wijzigingen van twee verschillende versies van een binair bestand niet samenvoegen, zelfs niet als de beide versies een gemeenschappelijke bovenliggende versie hebben. Als twee personen tegelijkertijd aan hetzelfde bestand werken, moeten ze samenwerken om hun wijzigingen af te stemmen om te voorkomen dat het werk van de andere persoon wordt overschreven. Git LFS biedt bestandsvergrendeling om u te helpen. Gebruikers moeten er nog steeds voor zorgen dat ze altijd de meest recente kopie van een binaire asset ophalen voordat ze aan het werk gaan.
  • Azure-opslagplaatsen bieden momenteel geen ondersteuning voor het gebruik van Secure Shell (SSH) in opslagplaatsen met bijgehouden Git LFS-bestanden.
  • Als een gebruiker een binair bestand via de webinterface naar een opslagplaats sleept die is geconfigureerd voor Git LFS, wordt het binaire bestand doorgevoerd in de opslagplaats, niet de aanwijzers die via de Git LFS-client worden doorgevoerd.
  • Hoewel er geen strikte beperking voor de bestandsgrootte is, kan de beschikbare vrije ruimte van de server en de huidige workload de prestaties en functionaliteit beperken.
  • De tijdslimiet voor het uploaden van één bestand is één uur.

File format

Het bestand dat is geschreven naar uw opslagplaats voor een bijgehouden Git LFS-bestand heeft een paar regels met een sleutel/waardepaar op elke regel:

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

Notitie

De GitHub-URL die is opgenomen voor de versiewaarde definieert alleen het bestandstype LFS-aanwijzer. Het is geen koppeling naar uw binaire bestand.

Bekende problemen

Als u een versie van LFS eerder dan 2.4.0 met Azure DevOps Server gebruikt, is een extra installatiestap vereist voor verificatie via NTLM in plaats van Kerberos. Deze stap is niet meer nodig vanaf LFS 2.4.0 en we raden u ten zeerste aan een upgrade uit te voeren.