Amikor a Git-et Bitbucketen tárolja, 2 GB-os kemény korlát van érvényben - ha ezt túllépik, akkor csak olvasható hozzáféréssel rendelkezik a tárházhoz. Ennek megakadályozása érdekében visszamenőlegesen eltávolíthatja a nagy mappákat vagy fájlokat a vállalásokból. De más esetekben is (ha a hozzáférési adatok beléptek az előzményekbe, vagy ha a node_modules visszacsúszott a mesterbe), akkor a természetével ellentétben manipulálnia kell a Git történetét.
A Bitbucket erről maga is részletes cikket írt. Ahhoz, hogy az egészet egy ügyben végig tudjuk futtatni, először létre kell hoznunk egy új tárat:
Ezután klónozzuk az adattárat egy üres mappába a helyi gépen:
6ab7686fc508ce87c52b10bb5d01ee51
Most két almappát hozunk létre véletlenszerű tartalmú fájlokkal:
6ab7686fc508ce87c52b10bb5d01ee51
Most a mestert nyomjuk:
6ab7686fc508ce87c52b10bb5d01ee51
Most már majdnem elértük a 2 GB-os kemény határt a Bitbucket-en:
Ezt helyben is ellenőrizhetjük (lásd: "size-pack"):
6ab7686fc508ce87c52b10bb5d01ee51
A feladat most az, hogy visszamenőlegesen távolítsa el a "foo" -t az adattárból, hogy felére csökkentsék a méretét. Ehhez először szerkesztjük az aktuális HEAD-t, és a mappát a gitignore-ra írjuk:
6ab7686fc508ce87c52b10bb5d01ee51
Végül eltávolítjuk a mappát a BFG Repo Cleaner segítségével (a BFG rendszerkövetelményként aktuális JRE-t igényel a rendszeren):
6ab7686fc508ce87c52b10bb5d01ee51
Most lokálisan láthatjuk az eredményt:
6ab7686fc508ce87c52b10bb5d01ee51
De a Bitbucket-en a tároló mérete még nem változott, mert a szemétszedőt még nem hajtották végre távolról, és a bitbucket nem hajt végre "git gc" -t minden egyes lökéssel:
Ezt a támogatás is megerősíti:
Ezért a legjobb, ha közvetlenül a support@bitbucket.org címre küldünk egy kérést a "git gc" kézi futtatásához a tárban. Rövid idő után ezt a támogató csapat is elvégezte:
Ha "frissen" áthelyezi az adattárat egy másik számítógépre, csak 0,9 GB kerül a lemezre. Ha valakinek az 1,8 GB-os verziója helyben elérhető, akkor elegendő a "git pull", majd a "git gc".