Érzékeny adatok vagy túl sok memóriafelhasználás: Jó okai vannak a Git-előzmények módosításának. Ebben a blogbejegyzésben elmagyaráztam, hogyan lehet fájlokat törölni a Git előzményeiből a BFG használatával. A BFG gyenge pontja a közvetlen elérési utak támogatásának hiánya, ezért nem lehet kifejezetten eltávolítani az almappákban lévő fájlokat vagy mappákat az előzményekből. Ezzel itt az ideje alternatív megoldások után nézni.
A hivatalosan nem ajánlott git filter ág mellett a git-filter-repo az egyik eszköz az előzmények megtisztítására. Rövid telepítés után először elemezzük a tárolót, és megtaláljuk például a történelem legnagyobb mappáit:
git filter-repo --analyze
Hát legyen a mappában .git/filter-repo/analysis
mindenféle TXT fájlt generált:
directories-all-sizes.txt
extensions-all-sizes.txt
path-all-sizes.txt
- ...
Megéri a fájlt directories-all-sizes.txt
nézd meg közelebbről:
=== All directories by reverse size ===
Format: unpacked size, packed size, date deleted, directory name
4624417043 3796607988 <present> <toplevel>
4475940396 3778033787 <present> wp-content
4060236681 3694449320 <present> wp-content/uploads
305163809 70576241 <present> wp-content/plugins
123818107 15442735 <present> wp-includes
...
Gyakran előfordul, hogy régóta figyelmen kívül hagyta és eltávolította a HEAD adatokat az előzményekből (például a WordPress médiamappából wp-content/uploads/
vagy egy véletlenül meglökött node_modules
- vagy vendor
-Kötőanyag).
Általában ajánlja git-filter-repo
tisztítás után új, üres tárolóba tolva. Számos oka van itt felsorolva, miért van ennek értelme és sok probléma elkerülhető. Ennek ellenére megtörténhet, hogy ugyanabba a tárolóba szeretne tolni, és ez is lehetséges néhány tippel.
Fontos, hogy a főbb kódtárhely-platformok GitHub és GitLab különböző megközelítéseket ajánlanak, amelyek közül néhány különbözik egymástól. Például a GitHubon eltávolítjuk wp-content/uploads/
a következő lépések segítségével git-filter-repo
a történelemből:
mkdir tmp-repo
cd tmp-repo
git clone git@github.com:foo/bar.git .
cp .git/config /tmp/config-backup
git filter-repo --invert-paths --path wp-content/uploads/
# option 1: same repo
mv /tmp/config-backup .git/config
git push origin --force --all
# option 2: new repo
git remote add origin git@github.com:foo/bar-new.git
git push origin --force --all
cd ..
rm -rf tmp-repo
Most már távolról is ellenőrizhetjük a méretet (a méret módosítása API-n keresztül és a felhasználói felületen akár 24 órát is igénybe vehet). Ehhez nyissa meg a lerakat beállításait (ha a lerakat egy szervezethez tartozik, először hozzá kell adnia a saját fiókját a szervezethez). Most látjuk a méretet:
Az eljárás kissé eltér a GitLab-on:
mkdir tmp-repo
cd tmp-repo
# option 1: same repo
# Settings > General > Advanced > Export project > download tar.gz file into tmp-repo
tar xzf 20*.tar.gz
git clone --bare --mirror project.bundle
cd project.git
git filter-repo --invert-paths --path wp-content/uploads/
cp ./filter-repo/commit-map /tmp/commit-map-1
# copying the commit-map has to be done after every single command from git filter-repo
# you need the commit-map files later
git remote remove origin
git remote add origin git@gitlab.com:foo/bar.git
# Settings > Repository > Protected branches/Protected branches >
# enable "Allowed to force push to main/master"
git push origin --force 'refs/heads/*'
git push origin --force 'refs/tags/*'
git push origin --force 'refs/replace/*'
# Settings > Repository > Protected branches/Protected branches >
# disable "Allowed to force push to main/master"
date
# wait 30 minutes (😱)
date
# Settings > Repository > upload /tmp/commit-map-X
# option 2: new repo
git clone git@gitlab.com:foo/bar.git .
git filter-repo --invert-paths --path wp-content/uploads/
git remote add origin git@gitlab.com:foo/bar-new.git
# Settings > Repository > Protected branches/Protected branches >
# enable "Allowed to force push to main/master"
git push origin --force --all
# Settings > Repository > Protected branches/Protected branches >
# disable "Allowed to force push to main/master"
cd ..
rm -rf tmp-repo
Újabb ~5 perc várakozás után mehetünk alá Settings > Usage Quotas
tárhely megtekintése:
Az eltávolítás után fontos, hogy minden érintett fejlesztő részt vegyen az utolsó lépésekben: Ha egy felhasználó most normál leküldést hajt végre a saját helyi másolatával, akkor a nagy fájlok visszavándorolnak a központi tárolóba. Ezért a következő 3 lehetőség javasolt:
- "szegény ember friss klónja"
rm -rf .git && git clone xxx temp && mv temp/.git ./.git && rm -rf temp
- Módosított fájlokhoz (alkalmazástól függően):
git checkout -- .
vagy.git add -A . && git commit -m "Push obscure file changes." && git push
- "elölről kezd"
rm -rf repo && git clone xxx .
- "csúnya húzás rebase-el"
git pull -r
- Itt még mindig megvan a tisztítatlan előzmény, de a legtöbb esetben már véletlenül sem írja felül a távoli tárolót a nagy helyi változattal
A jelenlegi kvóták során (főleg a GitLab új megszorításai miatt ) mindig érdemes ellenőrizni a tárhelyeid előzményeinek méretét, és szükség esetén kitisztítani:
GitHub ingyenes | GitLab ingyenes | |
Maximális fájlméret korlát | 100 MB | ∞ |
Max repo méretkorlát | 5000 MB | ∞ |
Maximális repószám korlát | ∞ | ∞ |
Maximális teljes méretkorlát | ∞ | 5000 MB |
Végül érdemes egy pillantást vetni egy saját üzemeltetésű, ingyenes változatra is, mint pl Gitea dobni. Kis erőfeszítéssel a nagyon vékony szerver egy saját üzemeltetésű Git-példány (GUI per SSL biztosított, Biztonsági mentés tartalmazza, irányítani erős API) fogadó, amelyek szintén kiválóak Beállítás és adatvédelmi szempontból is felsőbbrendű. Itt egyébként is használhatod git-filter-repo
Egyszerűen egyszerűsítse a tárolókat:
mkdir tmp-repo
cd tmp-repo
git clone git@git.tld.com:foo/bar.git .
cp .git/config /tmp/config-backup
git filter-repo --invert-paths --path wp-content/uploads/
# option 1: same repo
mv /tmp/config-backup .git/config
git push origin --mirror
# login on the remote command line and run in the repo-folder
sudo -u git git reflog expire --expire=now --all
sudo -u git git gc --aggressive --prune=now
# if you face memory limit issues, modify the git configuration
sudo -u git git config --global pack.windowMemory "100m"
sudo -u git git config --global pack.packSizeLimit "100m"
sudo -u git git config --global pack.threads "1"
# if in web ui the size does not change, make a slight
# modification to a file and push again normally
# option 2: new repo
git remote add origin git@git.tld.com:foo/bar-new.git
git push origin --force --all
cd ..
rm -rf tmp-repo
Itt konkrétan a parancs sudo -u git git gc --aggressive --prune=now
fontos (a cron fut git gc
egyébként túl hosszú metszés ideje 2 hetes).