Når du hoster Git på Bitbucket , er der en hård grænse på 2 GB - hvis denne overskrides, har du kun skrivebeskyttet adgang til depotet. For at forhindre dette kan du for eksempel med tilbagevirkende kraft fjerne store mapper eller filer fra dine commits. Men også i andre tilfælde (hvis adgangsdata har fundet vej ind i historikken eller node_modules er faldet til at mestre igen) er du nødt til at manipulere Gits historie med tilbagevirkende kraft, i modsætning til dens natur.
Bitbucket har skrevet en detaljeret artikel om dette selv. For at køre det hele igennem på en sag opretter vi først et nyt lager:
Derefter kloner vi lageret til en tom mappe på den lokale maskine:
6ab7686fc508ce87c52b10bb5d01ee51
Nu opretter vi to undermapper med filer med tilfældigt indhold:
6ab7686fc508ce87c52b10bb5d01ee51
Vi skubber nu på mester:
6ab7686fc508ce87c52b10bb5d01ee51
Nu har vi næsten nået den hårde grænse på 2 GB på Bitbucket:
Vi kan også kontrollere dette lokalt (se "størrelse-pakke"):
6ab7686fc508ce87c52b10bb5d01ee51
Opgaven er nu at fjerne "foo" fra arkivet med tilbagevirkende kraft for at skære størrelsen i halve. For at gøre dette redigerer vi først den aktuelle HEAD og skriver mappen i gitignore:
6ab7686fc508ce87c52b10bb5d01ee51
Endelig fjerner vi mappen ved hjælp af BFG Repo Cleaner (BFG kræver en nuværende JRE på systemet som et systemkrav):
6ab7686fc508ce87c52b10bb5d01ee51
Vi kan nu se resultatet lokalt:
6ab7686fc508ce87c52b10bb5d01ee51
Depotstørrelsen er dog ikke ændret på Bitbucket, fordi affaldssamleren endnu ikke er udført eksternt, og bitbucket udfører ikke en "git gc" med hvert skub.:
Dette bekræftes også af støtten:
Så det er bedst at sende en anmodning direkte til support@bitbucket.org om manuelt at køre "git gc" i lageret. Efter kort tid blev dette også gjort af supportteamet:
Hvis du "frisk" flytter lageret til en anden computer, vil kun 0,9 GB havne på disken. Hvis nogen har 1,8 GB-versionen tilgængelig lokalt, er en "git pull" efterfulgt af "git gc" tilstrækkelig.