Følsomme data eller for meget hukommelsesforbrug: Der er gode grunde til at ændre Git-historikken. I dette blogindlæg forklarede jeg, hvordan man fjerner filer fra Git-historien ved hjælp af BFG . Et svagt punkt ved BFG er manglen på understøttelse af direkte stier , så du kan ikke specifikt fjerne filer eller mapper i undermapper fra historikken. Med det er det tid til at se på alternative løsninger.
Ud over den officielt ikke anbefalede git-filtergren , er git-filter-repo et af værktøjerne til at rydde op i historien. Efter en kort installation analyserer vi først depotet og finder for eksempel historiens største mapper:
git filter-repo --analyzeGodt være i mappen .git/filter-repo/analysis genereret alle mulige TXT-filer:
directories-all-sizes.txtextensions-all-sizes.txtpath-all-sizes.txt- ...
Det er filen værd directories-all-sizes.txt se nærmere:
=== 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
...Det sker ofte, at du længe har ignoreret og fjernet fra HEAD-dataene i historikken (f.eks. WordPress-mediemappen wp-content/uploads/ eller en ved et uheld skubbet en node_modules- eller vendor-Ringbind).
Anbefaler generelt git-filter-repo efter rengøring, skubbe til et nyt, tomt depot. Der er talrige årsager anført her, hvorfor dette giver mening og undgår mange problemer. Ikke desto mindre kan det ske, at du vil skubbe til det samme lager, og det er også muligt med et par hints.
Vigtigere er de store kode-hosting-platforme GitHub og GitLab anbefale forskellige tilgange, hvoraf nogle adskiller sig fra hinanden. For eksempel fjerner vi på GitHub wp-content/uploads/ ved hjælp af følgende trin git-filter-repo fra historien:
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-repoVi kan nu også kontrollere størrelsen eksternt (at ændre størrelsen via API og i brugergrænsefladen kan tage op til 24 timer). For at gøre dette skal du åbne lagerindstillingerne (hvis lageret tilhører en organisation, skal du først tilføje din egen konto til organisationen). Nu ser vi størrelsen:
Proceduren er lidt anderledes på 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-repoEfter endnu en ventetid på ~5 minutter kan vi gå under Settings > Usage Quotas se lagerplads:
Efter fjernelsen er det vigtigt, at alle involverede udviklere er involveret i de sidste trin: Hvis en bruger nu udfører et normalt push med sin egen lokale kopi, vil det resultere i, at de store filer migrerer tilbage til det centrale lager. Derfor anbefales følgende 3 muligheder:
- "fattigmands friske klon"
rm -rf .git && git clone xxx temp && mv temp/.git ./.git && rm -rf temp- For ændrede filer (afhængigt af applikationen):
git checkout -- .eller.git add -A . && git commit -m "Push obscure file changes." && git push
- "start fra begyndelsen"
rm -rf repo && git clone xxx .
- "grimt træk med rebase"
git pull -r- Her har du stadig den urensede historie, men i de fleste tilfælde overskriver du ikke længere ved et uheld fjernlageret med den store lokale variant
I løbet af de nuværende kvoter (især på grund af de nye begrænsninger af GitLab ), er det altid værd at tjekke størrelsen af historikken for dine depoter og rydde op i dem, hvis det er nødvendigt:
| GitHub gratis | GitLab gratis | |
| Maks. filstørrelsesgrænse | 100 MB | ∞ |
| Maks. repos størrelsesgrænse | 5.000 MB | ∞ |
| Maks. reposantalgrænse | ∞ | ∞ |
| Maks. samlet størrelsesgrænse | ∞ | 5.000 MB |
Endelig er det også værd at tage et kig på en selv-hostet, gratis variant som Gitea at kaste. Med lidt indsats kan du på en meget slank server en selvhostet Git-instans (GUI pr SSL sikret, Backup inkluderet, kontrol over kraftfuld API) vært, som også er fremragende konfigurere og er også overlegen med hensyn til databeskyttelse. Her kan du i øvrigt også bruge git-filter-repo Du skal blot strømline depoter:
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-repoHer er kommandoen specifikt sudo -u git git gc --aggressive --prune=now vigtigt (cron kører git gc ellers har en for lang beskære tid 2 uger).