Curățați istoricul Git partea 208
22

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).