Date sensibile sau consum prea mare de memorie: Există motive întemeiate să doriți să schimbați istoricul Git. În această postare pe blog , am explicat cum să ștergeți fișierele din istoricul Git folosind BFG . Un punct slab al BFG este lipsa suportului pentru căile directe , așa că nu puteți elimina în mod specific fișierele sau folderele din subfoldere din istoric. Cu asta, este timpul să ne uităm la soluții alternative.
În plus față de ramura git filter nerecomandată oficial , git-filter-repo este unul dintre instrumentele pentru curățarea istoricului. După o scurtă instalare , analizăm mai întâi depozitul și găsim, de exemplu, cele mai mari foldere din istorie:
git filter-repo --analyze
Ei bine, fii în dosar .git/filter-repo/analysis
a generat tot felul de fișiere TXT:
directories-all-sizes.txt
extensions-all-sizes.txt
path-all-sizes.txt
- ...
Merita dosarul directories-all-sizes.txt
priveste mai atent:
=== 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
...
Se întâmplă adesea să fi ignorat și să fi eliminat de mult timp datele HEAD din istoric (de exemplu, folderul media WordPress wp-content/uploads/
sau unul împins accidental node_modules
- sau vendor
-Liant).
Recomanda in general git-filter-repo
după curățare, împingând într-un depozit nou, gol. Există numeroase motive enumerate aici, de ce acest lucru are sens și evită multe probleme. Cu toate acestea, se poate întâmpla să doriți să împingeți în același depozit și acest lucru este posibil și cu câteva indicii.
Important, principalele platforme de găzduire a codurilor GitHub și GitLab recomandă abordări diferite, dintre care unele diferă unele de altele. De exemplu, pe GitHub eliminăm wp-content/uploads/
folosind următorii pași git-filter-repo
din istorie:
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
Acum putem verifica și dimensiunea de la distanță (schimbarea dimensiunii prin API și în UI poate dura până la 24 de ore). Pentru a face acest lucru, deschideți setările depozitului (dacă depozitul aparține unei organizații, trebuie mai întâi să adăugați propriul cont la organizație). Acum vedem dimensiunea:


Procedura este ușor diferită pe GitLab:
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
După încă o așteptare de aproximativ 5 minute, putem trece Settings > Usage Quotas
vizualizați spațiul de depozitare:


După eliminare, este important ca toți dezvoltatorii implicați să fie implicați în pașii finali: dacă un utilizator realizează acum un push normal cu propria copie locală, acest lucru ar duce la migrarea fișierelor mari înapoi la depozitul central. Prin urmare, sunt recomandate următoarele 3 opțiuni:
- "clona proaspătă a săracului"
rm -rf .git && git clone xxx temp && mv temp/.git ./.git && rm -rf temp
- Pentru fișierele modificate (în funcție de aplicație):
git checkout -- .
sau.git add -A . && git commit -m "Push obscure file changes." && git push
- "începe de la zero"
rm -rf repo && git clone xxx .
- "tragere urata cu rebase"
git pull -r
- Aici aveți încă istoricul necurățat, dar în cele mai multe cazuri nu mai suprascrieți accidental depozitul de la distanță cu varianta locală mare
În cursul cotelor actuale (în special din cauza noilor restricții ale GitLab ), merită întotdeauna să verificați dimensiunea istoricului depozitelor dvs. și să le curățați dacă este necesar:
GitHub gratuit | GitLab gratuit | |
Limită de dimensiune maximă a fișierului | 100 MB | ∞ |
Limită de dimensiune maximă a depozitului | 5.000 MB | ∞ |
Limită maximă a numărului de repo | ∞ | ∞ |
Limită maximă de dimensiune totală | ∞ | 5.000 MB |
În cele din urmă, merită să aruncați o privire și la o variantă gratuită, auto-găzduită, cum ar fi Gitea a arunca. Cu puțin efort puteți pe a server foarte subțire o instanță Git auto-găzduită (GUI per SSL asigurat, Backup inclus, control asupra API puternic), care sunt de asemenea excelente configurați și este, de asemenea, superior în ceea ce privește protecția datelor. Aici, apropo, puteți folosi și git-filter-repo
Pur și simplu eficientizați depozitele:
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
Aici este în mod special comanda sudo -u git git gc --aggressive --prune=now
important (funcția cron git gc
altfel are unul prea lung timp de prune de 2 săptămâni).