Pastroni historinë e Git, pjesën 2

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

GitHub: hapësira në disk përpara pastrimit
GitHub: hapësira në disk pas pastrimit

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:

GitLab: hapësira në disk përpara pastrimit
GitLab: hapësira në disk pas pastrimit

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 falasGitLab Falas
Kufiri maksimal i madhësisë së skedarit100 MB
Kufiri maksimal i madhësisë së repos5000 MB
Kufiri maksimal i numrit të repove
Kufiri maksimal i madhësisë së përgjithshme5000 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).

Mbrapa