Ryd op i Git historie del 2

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 --analyze

Godt være i mappen .git/filter-repo/analysis genereret alle mulige TXT-filer:

  • directories-all-sizes.txt
  • extensions-all-sizes.txt
  • path-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).

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
mv /tmp/config-backup .git/config
git push origin --force --all
git push origin --force --tags
# check size locally
git gc && git count-objects -vH
cd ..
rm -rf tmp-repo

Vi 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:

GitHub: diskplads før oprydning
GitHub: diskplads efter oprydning

Proceduren er lidt anderledes på GitLab:

mkdir tmp-repo
cd tmp-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 on main/master"
cd ./../../
rm -rf tmp-repo
date
# wait 30 minutes (😱)
date
# Settings > Repository > upload /tmp/commit-map-X

Efter endnu en ventetid på ~5 minutter kan vi gå under Settings > Usage Quotas se lagerplads:

GitLab: diskplads før oprydning
GitLab: diskplads efter oprydning

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:

  • rm -rf .git && git clone xxx temp && mv temp/.git ./.git && rm -rf temp && git add -A .
    ("fattigmands friske klon", genklon ind i eksisterende depot)
  • rm -rf repo && git clone xxx .
    ("start fra bunden", den reneste variant)
  • git pull -r
    ("træk med rebase", du har stadig den urensede historie, men overskriver ikke længere ved et uheld)

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 gratisGitLab gratis
Maks. filstørrelsesgrænse100 MB
Maks. repos størrelsesgrænse5.000 MB
Maks. reposantalgrænse
Maks. samlet størrelsesgrænse5.000 MB

Endelig er det også værd at tage et kig på en selv-hostet, gratis variant som Gitea . Med en lille indsats kan du hoste en selvhostet Git-instans (GUI sikret med SSL , backup inkluderet, kontrol via kraftfuld API ) på en meget mager server , som også kan konfigureres fremragende og også er overlegen med hensyn til databeskyttelse.

Tilbage