Mijn project is zes maanden oud en git is heel erg traag. We volgen ongeveer 30 bestanden met een grootte van 5 MB tot 50 MB. Dat zijn binaire bestanden en we bewaren ze in git. Ik geloof dat die bestanden git traag maken.

Is er een manier om alle bestanden met de grootte > 5 MB uit de repository. Ik weet dat ik al deze bestanden zou verliezen en dat vind ik oké.

Idealiter zou ik een commando willen dat alle grote bestanden weergeeft ( > 5MB) . Ik kan de lijst zien en dan zeg ik oké, ga je gang en verwijder die bestanden en maak git sneller.

Ik moet vermelden dat git niet alleen traag is op mijn computer, maar dat het implementeren van de app in de staging-omgeving nu ongeveer 3 uur duurt.

Dus de oplossing zou iets moeten zijn dat de server zal beïnvloeden en niet alleen de gebruikers van de repository.

Antwoord 1, autoriteit 100%

Verzamelt u afval?

git gc

Dit maakt een aanzienlijk verschil in snelheid, zelfs voor kleine opslagplaatsen.

Antwoord 2, autoriteit 64%

Uitleg

Git is echt goed in enorme geschiedenissen van kleine tekstbestanden, omdat het ze en hun wijzigingen efficiënt kan opslaan. Tegelijkertijd is git erg slecht in binaire bestanden en zal het naïef afzonderlijke kopieën van het bestand opslaan (standaard, tenminste). De repository wordt enorm, en dan wordt het traag, zoals je hebt gezien.

Dit is een veelvoorkomend probleem bij DVCS’s, verergerd door het feit dat je elke versie van elk bestand (“de hele repository”) elke keer dat je kloont downloadt. De jongens van Kilnwerken aan een plug-in om deze grote bestanden meer als Subversion te behandelen, die alleen historische versies op aanvraag.

Oplossing

Deze opdracht geeft een lijst van alle bestanden in de huidige map met een grootte van >= 5 MB.

find . -size +5000000c 2>/dev/null -exec ls -l {} \;

Als je de bestanden uit de hele geschiedenis van de repository wilt verwijderen, kun je dit idee gebruiken met git filter-branchom door de geschiedenis te lopen en alle sporen van grote bestanden te verwijderen. Nadat je dit hebt gedaan, zullen alle nieuwe klonen van de repository slanker zijn. Als u een repository wilt uitbreiden zonder te klonen, vindt u instructies op de man-pagina(zie “Checklist voor het verkleinen van een repository”).

git filter-branch --index-filter \
    'find . -size +5000000c 2>/dev/null -exec git rm --cached --ignore-unmatch {} \;'

Een woord van waarschuwing: hierdoor wordt uw repository incompatibelmet andere klonen, omdat er voor de bomen en indexen verschillende bestanden zijn ingecheckt; je kunt er niet meer aan duwen of trekken.

Antwoord 3, autoriteit 13%

Hier is een gecensureerde herziening die bedoeld is om minder negatief en opruiend te zijn:

Git heeft een bekende zwakte als het gaat om bestanden die geen regel voor regel tekstbestanden zijn. Er is momenteel geen oplossing en er zijn geen plannen aangekondigd door het kernteam van git om dit aan te pakken. Er zijn oplossingen als uw project klein is, bijvoorbeeld 100 MB of zo. Er bestaan ​​branches van het git-project om dit schaalbaarheidsprobleem aan te pakken, maar deze branches zijn op dit moment nog niet volwassen. Sommige andere revisiecontrolesystemen hebben dit specifieke probleem niet. Je zou dit probleem als slechts een van de vele factoren moeten beschouwen wanneer je besluit om git te selecteren als je revisiecontrolesysteem.

Antwoord 4, autoriteit 12%

Er is niets specifieks over binaire bestanden en de manier waarop git ermee omgaat. Wanneer je een bestand toevoegt aan een git-repository, wordt een header toegevoegd en wordt het bestand gecomprimeerd met zlib en hernoemd naar de SHA1-hash. Dit is precies hetzelfde, ongeacht het bestandstype. Er is niets in zlib-compressie dat het problematisch maakt voor binaire bestanden.

Maar op sommige punten (duwen, gc) begon Git te kijken naar de mogelijkheid om inhoud te deltacomprimeren. Als git bestanden vindt die vergelijkbaar zijn (bestandsnaam enz.), zet het ze in RAM en begint het ze samen te comprimeren. Als je 100 bestanden hebt en elk van hen is bijvoorbeeld 50 MB, dan zal het proberen om tegelijkertijd 5 GB in het geheugen te plaatsen. Hier moet je nog wat aan toevoegen om dingen te laten werken. Uw computer heeft mogelijk niet deze hoeveelheid RAM en begint te wisselen. Het proces kost tijd.

Je kunt de diepte van de deltacompressie beperken, zodat het proces niet zoveel geheugen gebruikt, maar het resultaat is een minder efficiënte compressie. (core.bigFileThreshold, delta-attribuut, pack.window, pack.depth, pack.windowMemory enz.)

Er zijn dus veel dingen die je kunt doen om git heel goed te laten werken met grote bestanden.

Antwoord 5, autoriteit 5%

Eén manier om dingen te versnellen is door de vlag --depth 1te gebruiken. Zie de man-pagina voor details. Ik ben geen geweldige git-goeroe, maar ik geloof dat dit zegt: doe het equivalent van een p4 getof een svn get, dat wil zeggen dat het je alleen de nieuwste bestanden geeft in plaats van “geef me de hele tijd alle revisies van alle bestanden”, dat is wat git clonedoet.

Antwoord 6, autoriteit 3%

heb je git verteld dat die bestanden binair zijn?

bijv. *.ext binarytoegevoegd aan de .gitattributes

van je repository

Antwoord 7, autoriteit 3%

Je kunt BFG Repo Cleaner ook beschouwen als een snellere en gemakkelijkere manier om grote bestanden op te ruimen.

https://rtyley.github.io/bfg-repo-cleaner/

Antwoord 8, autoriteit 2%

Ik gebruik Git sinds 2008 zowel op Windows als op GNU/linux en de meeste bestanden die ik volg zijn binaire bestanden. Sommige van mijn repo’s zijn meerdere GB en bevatten JPEG en andere media.
Ik heb veel computers zowel thuis als op het werk met Git.

Ik heb nog nooit de symptomen gehad die in het oorspronkelijke bericht worden beschreven. Maar slechts een paar weken geleden installeerde ik MsysGit op een oude Win-XP-laptop en bijna wat ik ook deed, het bracht git tot stilstand. Zelfs testen met slechts twee of drie kleine tekstbestanden was belachelijk traag. We hebben het over 10 minuten om een ​​bestand van minder dan 1k toe te voegen… het lijkt alsof de git-processen voor altijd in leven zijn gebleven. Al het andere werkte zoals verwacht op deze computer.
Ik heb een downgrade gedaan van de nieuwste versie naar 1.6 en de problemen waren verdwenen…
Ik heb andere laptops van hetzelfde merk, ook met Win-XP geïnstalleerd door dezelfde IT-afdeling met dezelfde afbeelding, waar Git prima werkt, ongeacht de versie…
Er moet dus iets vreemds aan de hand zijn met die specifieke computer.

Ik heb ook wat tests gedaan met binaire bestanden en compressie. Als je een BMP-afbeelding hebt en je maakt er kleine wijzigingen in en commit ze, dan zal git gc heel goed comprimeren.
Dus mijn conclusie is dat de compressie niet afhankelijk is van of de bestanden binair zijn of niet.

Antwoord 9

Stel gewoon in dat de bestanden worden genegeerd. Zie onderstaande link:

http://help.github.com/git-ignore/

Antwoord 10

Dat komt omdat git niet schaalbaar is.

Dit is een serieuze beperking in git die wordt overstemd door git-advocatuur. Zoek in de git-mailinglijsten en je zult honderden gebruikers vinden die zich afvragen waarom slechts een schamele 100 MB aan afbeeldingen (bijvoorbeeld voor een website of applicatie) git op de knieën brengt. Het probleem lijkt te zijn dat bijna alle git afhankelijk is van een optimalisatie die ze “packing” noemen. Helaas is het inpakken inefficiënt voor alle behalve de kleinste tekstbestanden (d.w.z. broncode). Erger nog, het wordt steeds minder efficiënt naarmate de geschiedenis vordert.

Het is echt een gênante fout in git, die wordt aangeprezen als “snel” (ondanks gebrek aan bewijs), en de git-ontwikkelaars zijn zich er terdege van bewust. Waarom hebben ze het niet opgelost? Je vindt reacties op de git-mailinglijst van git-ontwikkelaars die het probleem niet zullen herkennen omdat ze Photoshop-documenten (*.psd) een eigen formaat hebben. Ja, het is echt zo erg.

Dit is het resultaat:

Gebruik git voor kleine, broncode projecten waarvoor je geen zin hebt om een aparte repo op te zetten. Of voor kleine projecten met alleen broncode waarbij je wilt profiteren van git’s copy-the-hele-repo-model van gedecentraliseerde ontwikkeling. Of wanneer u gewoon een nieuwe tool wilt leren. Dit zijn allemaal goede redenen om git te gebruiken, en het is altijd leuk om nieuwe tools te leren.

Gebruik git niet als je een grote codebasis, binaire bestanden, enorme geschiedenis, enz. hebt. Slechts een van onze repo’s is een TB. Git kan het niet aan. VSS, CVS en SVN kunnen het prima aan. (SVN zwelt echter op.)

Geef git ook de tijd om te rijpen. Het is nog onvolwassen, maar het heeft veel vaart. Na verloop van tijd denk ik dat de praktische aard van Linus de OSS-puristen zal overwinnen, en git zal uiteindelijk bruikbaar zijn in het grotere veld.