Hoe Git LFS werkt: Overzicht van Git Opslag voor Grote Bestanden

Ontwikkelingsteams over de hele wereld gebruiken Git om broncode te beheren. En velen gebruiken Git LFS – Git Large File Storage – om grote bestanden te beheren en op te slaan. Hier leggen we uit wat Git LFS doet en wanneer je het moet gebruiken.

Kan Git grote bestanden aan?

Git kan grote bestanden niet in zijn eentje aan. Daarom voegen veel Git teams Git LFS toe om met grote bestanden in Git om te kunnen gaan.

Wat is Git LFS (Git Large File Storage)?

Git LFS is een Git-extensie die wordt gebruikt om grote bestanden en binaire bestanden in een aparte Git-repository te beheren.

De meeste projecten hebben tegenwoordig zowel code als binaire bestanden. En het opslaan van grote binaire bestanden in Git-repositories kan een knelpunt zijn voor Git-gebruikers.

Daarom voegen sommige Git gebruikers Git Large File Storage (LFS) toe.

Hoe werkt Git LFS?

Git LFS gebruikt pointers in plaats van de eigenlijke bestanden of binaire grote objecten (blobs).

Dus, in plaats van grote bestanden/blobs naar een Git repository te schrijven, schrijf je een pointer bestand. En de bestanden/blobs zelf worden naar een aparte server geschreven. Je kunt zelfs meerdere servers in Git LFS gebruiken.

Aan de slag gaan is vrij eenvoudig. Je download de extensie en configureert je bestandstypen.

Het gebruik van Git LFS maakt het mogelijk om grote bestanden te versienen (en blobs te beheren) terwijl je ruimte vrij maakt in Git repositories. En Git LFS is vaak een oplossing voor het pushen van grote bestanden naar GitHub.

Git Problemen Buiten LFS

Git heeft problemen buiten Git LFS. En beveiliging is een grote. Native Git mist beveiliging, en de add-on opties om Git te beveiligen zijn niet geweldig. Lees wat je zou moeten doen aan Git beveiliging in onze whitepaper – Hoe Git te locken.

Lock Down Git

Moet ik Git LFS gebruiken?

Je zou Git LFS moeten gebruiken als je grote bestanden of binaire bestanden hebt om in Git repositories op te slaan.

Dat komt omdat Git gedecentraliseerd is. Dus, iedere ontwikkelaar heeft de volledige verander historie op zijn computer. En veranderingen in grote binaire bestanden zorgen ervoor dat Git repositories groeien met de grootte van dat bestand, iedere keer als het bestand veranderd wordt (en die verandering gecommit wordt). Dat betekent dat het eeuwen zal duren om de bestanden te krijgen. En als je dat doet, zal het moeilijk zijn om de binaries te versienen en samen te voegen.

Dus, iedere keer als de bestanden groeien, groeit de Git repository. En als Git gebruikers een repository moeten ophalen en clonen, geeft dat problemen.

Git LFS is gemaakt om deze problemen op te lossen. Maar het heeft zelf ook problemen…

Wanneer Git opslag van grote bestanden niet werkt

Git LFS werkt. Maar teams vertellen ons voortdurend dat het moeilijk te beheren is. Dus, ook al is Git zelf gratis, het kan productiviteitskosten met zich meebrengen.

Installeren van Git LFS op iedere server en werkstation (en/of repo) kost tijd. Het belast ook beheerders. Als het eenmaal geïnstalleerd is, is er geen zicht en weinig controle over. En als sommige ontwikkelaars de Git LFS extensie niet hebben? Dan valt het uit elkaar.

Het kost extra stappen om Git Large File Storage te onderhouden met build runners, zoals Jenkins. Dat leidt tot extra tijd – en extra complexiteit.

Dit alles kan leiden tot prestatie problemen.

Alternatieven voor Git LFS

Git LFS is niet de enige manier om grote bestanden in Git te beheren. Er zijn alternatieven.

Dit omvat andere open source of derde partij oplossingen, zoals:

  • git-annex
  • git-bigfiles
  • git-fat
  • git-media
  • git-bigstore
  • git-sym

Maar, net als Git LFS, kunnen deze Git opslagopties voor grote bestanden problemen veroorzaken. Er is een betere manier om grote bestanden en binaire bestanden te beheren.

De beste versie controle voor grote binaire bestanden: Helix Core

De projecten van vandaag zijn groter, met meer bestanden en gemengde middelen dan ooit tevoren. Git en Git LFS alleen kunnen dat niet aan. Maar Helix Core kan dat wel.

Helix Core – versiebeheersoftware van Perforce – is de beste optie voor het beheren van grote binaire bestanden. Dat komt omdat de opslag van grote bestanden een native mogelijkheid is, geen add-on. En het is kogelvrij.

In Helix Core kunt u binaire bestanden opslaan naast uw broncode. In feite kunnen al je grootste bestanden – binaire bestanden, broncode, kunstbestanden, videobestanden, afbeeldingen, bibliotheken en build artefacten – samen in één repository worden opgeslagen. Zonder grote, verspreide teams te vertragen.

Zie u zelf waarom Helix Core de tool bij uitstek is voor het beheer van grote binaire bestanden.

Beheer grote bestanden in Helix Core

Tussen haakjes, Perforce heeft Git ook

Heeft u nog teams die grote bestanden in Git moeten beheren? Je kunt ze in je build pipeline opnemen met Perforce Git tools – Helix4Git en Helix TeamHub.

Helix4Git is een Git-server binnen een Perforce-server. Helix TeamHub is een oplossing voor het hosten van Git-code. Met deze tools kunnen Git-teams gebruikmaken van de snelheid en prestaties van Helix Core – terwijl ze in Git werken.

Zo kunt u Helix4Git naast Helix Core gebruiken om uw Git-repository in uw build pipeline te brengen. Met Helix4Git kunnen uw ontwikkelaars nog steeds hun eigen Git-tools gebruiken. Maar ze krijgen hun bestanden veel sneller.

U krijgt:

  • Snellere CI/CD build prestaties.
  • Ondersteuning voor multi-repo projecten, artefact repositories, en zelfs een Docker container register.
  • De mogelijkheid om geleidelijk nodes toe te voegen.
  • Replicatie en gegarandeerd up-to-date inhoud zonder vertraging, in plaats van kopiëren.

Leave a Reply