Të dhëna të ndjeshme ose konsum i tepërt i memories: Ka arsye të mira për të ndryshuar historinë e Git. Në këtë postim në blog , unë shpjegova se si të pastroni skedarët nga historia e Git duke përdorur BFG . Një pikë e dobët e BFG është mungesa e mbështetjes për shtigjet e drejtpërdrejta , kështu që nuk mund të hiqni në mënyrë specifike skedarët ose dosjet në nën-dosjet nga historia. Me këtë, është koha për të parë zgjidhje alternative.
Përveç degës së filtrit git që nuk rekomandohet zyrtarisht , git-filter-repo është një nga mjetet për pastrimin e historisë. Pas një instalimi të shkurtër, së pari analizojmë depon dhe gjejmë, për shembull, dosjet më të mëdha në histori:
git filter-repo --analyze
Pra, të jetë në dosje .git/filter-repo/analysis
gjeneroi të gjitha llojet e skedarëve TXT:
directories-all-sizes.txt
extensions-all-sizes.txt
path-all-sizes.txt
- ...
Ia vlen dosja directories-all-sizes.txt
hidhini një vështrim më të afërt:
=== 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
...
Shpesh ndodh që ju keni injoruar dhe hequr prej kohësh të dhënat HEAD në histori (për shembull, dosja e medias WordPress wp-content/uploads/
ose një i shtyrë aksidentalisht node_modules
- ose vendor
-Lidhës).
Në përgjithësi rekomandon git-filter-repo
pas pastrimit, duke shtyrë në një depo të re, të zbrazët. Ka shumë arsye të renditura këtu, pse kjo ka kuptim dhe shmang shumë probleme. Sidoqoftë, mund të ndodhë që të dëshironi të shtyni në të njëjtin depo dhe kjo është gjithashtu e mundur me disa sugjerime.
E rëndësishmja, platformat kryesore të pritjes së kodit GitHub dhe GitLab rekomandojnë qasje të ndryshme, disa prej të cilave ndryshojnë nga njëra-tjetra. Për shembull, në GitHub ne heqim wp-content/uploads/
duke përdorur hapat e mëposhtëm git-filter-repo
nga historia:
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
Tani mund të kontrollojmë madhësinë edhe nga distanca (ndryshimi i madhësisë nëpërmjet API dhe në UI mund të zgjasë deri në 24 orë). Për ta bërë këtë, hapni cilësimet e depove (nëse depoja i përket një organizate, së pari duhet të shtoni llogarinë tuaj në organizatë). Tani shohim madhësinë:
Procedura është paksa e ndryshme në 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
Pas një pritjeje tjetër prej ~ 5 minutash mund të kalojmë poshtë Settings > Usage Quotas
shikoni hapësirën e ruajtjes:
Pas heqjes, është e rëndësishme që të gjithë zhvilluesit e përfshirë të përfshihen në hapat përfundimtarë: Nëse një përdorues tani kryen një shtytje normale me kopjen e tij lokale, kjo do të rezultonte në migrimin e skedarëve të mëdhenj në depo qendrore. Prandaj, rekomandohen 3 opsionet e mëposhtme:
- "kloni i freskët i njeriut të varfër"
rm -rf .git && git clone xxx temp && mv temp/.git ./.git && rm -rf temp
- Për skedarët e ndryshuar (në varësi të aplikacionit):
git checkout -- .
ose.git add -A . && git commit -m "Push obscure file changes." && git push
- "filloni nga e para"
rm -rf repo && git clone xxx .
- "tërheqje e shëmtuar me ribazë"
git pull -r
- Këtu keni ende historinë e papastër, por në shumicën e rasteve nuk e mbishkruani më aksidentalisht depon në distancë me variantin e madh lokal
Në rrjedhën e kuotave aktuale (veçanërisht për shkak të kufizimeve të reja të GitLab ), ia vlen gjithmonë të kontrolloni madhësinë e historisë së depove tuaja dhe t'i pastroni ato nëse është e nevojshme:
GitHub falas | GitLab Falas | |
Kufiri maksimal i madhësisë së skedarit | 100 MB | ∞ |
Kufiri maksimal i madhësisë së repos | 5000 MB | ∞ |
Kufiri maksimal i numrit të repove | ∞ | ∞ |
Kufiri maksimal i madhësisë së përgjithshme | ∞ | 5000 MB |
Së fundi, ia vlen t'i hidhni një sy edhe një variant të vetë-strehuar, falas si Gitea të hedh. Me pak përpjekje mund të a server shumë i hollë një shembull Git i vetë-pritur (GUI per SSL siguruar, Rezervë përfshirë, kontroll mbi API e fuqishme) host, të cilat janë gjithashtu të shkëlqyera konfiguroni dhe është gjithashtu superiore përsa i përket mbrojtjes së të dhënave. Këtu, nga rruga, ju gjithashtu mund të përdorni git-filter-repo
Thjesht thjeshtoni depot:
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
Këtu është specifikisht komanda sudo -u git git gc --aggressive --prune=now
i rëndësishëm (cron running git gc
përndryshe ka një shumë të gjatë koha e krasitjes prej 2 javësh).