Sentemaj datumoj aŭ tro da memorkonsumo: Estas bonaj kialoj por voli ŝanĝi la Git-historion. En ĉi tiu bloga afiŝo , mi klarigis kiel purigi dosierojn el Git-historio uzante BFG . Malforta punkto de BFG estas la manko de subteno por rektaj vojoj , do vi ne povas specife forigi dosierojn aŭ dosierujojn en subdosierujoj de la historio. Kun tio, estas tempo rigardi alternativajn solvojn.
Krom la oficiale ne rekomendita git filter-branĉo , git-filter-repo estas unu el la iloj por purigi la historion. Post mallonga instalado , ni unue analizas la deponejon kaj trovas, ekzemple, la plej grandajn dosierujojn en la historio:
git filter-repo --analyzeNu estu en la dosierujo .git/filter-repo/analysis generis ĉiajn TXT-dosierojn:
directories-all-sizes.txtextensions-all-sizes.txtpath-all-sizes.txt- ...
Ĝi valoras la dosieron directories-all-sizes.txt rigardu pli proksime:
=== 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
...Ofte okazas, ke vi longe ignoris kaj forigis el la HEAD-datumoj en la historio (ekzemple, la WordPress-media dosierujo wp-content/uploads/ aŭ hazarde puŝita node_modules- aŭ vendor- Binder).
Ĝenerale rekomendas git-filter-repo post purigado, puŝado al nova, malplena deponejo. Estas multaj kialoj listigitaj ĉi tie, kial ĉi tio havas sencon kaj evitas multajn problemojn. Tamen, povas okazi, ke vi volas puŝi al la sama deponejo kaj tio ankaŭ eblas per kelkaj sugestoj.
Grave, la ĉefaj kodaj gastigaj platformoj GitHub kaj GitLab rekomendas malsamajn alirojn, iuj el kiuj diferencas unu de la alia. Ekzemple, en GitHub ni forigas wp-content/uploads/ uzante la sekvajn paŝojn git-filter-repo el la historio:
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-repoNi nun povas ankaŭ kontroli la grandecon malproksime (ŝanĝi la grandecon per API kaj en la UI povas daŭri ĝis 24 horoj). Por fari tion, malfermu la deponejon agordojn (se la deponejo apartenas al organizo, vi unue devas aldoni vian propran konton al la organizo). Nun ni vidas la grandecon:
La proceduro estas iomete malsama en 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-repoPost alia atendo de ~5 minutoj ni povas suben Settings > Usage Quotas vidi stokan spacon:
Post la forigo, estas grave ke ĉiuj programistoj implikitaj estas implikitaj en la finaj paŝoj: Se uzanto nun faras normalan puŝon kun sia propra loka kopio, tio rezultigus la grandajn dosierojn migras reen al la centra deponejo. Tial, la sekvaj 3 opcioj estas rekomenditaj:
- "la freŝa klono de malriĉulo"
rm -rf .git && git clone xxx temp && mv temp/.git ./.git && rm -rf temp- Por ŝanĝitaj dosieroj (depende de la aplikaĵo):
git checkout -- .aŭ.git add -A . && git commit -m "Push obscure file changes." && git push
- "komenci de nulo"
rm -rf repo && git clone xxx .
- "malbela tiro kun rebazo"
git pull -r- Ĉi tie vi ankoraŭ havas la nepurigitan historion, sed plejofte vi ne plu hazarde anstataŭigas la foran deponejon per la granda loka varianto.
Dum la nunaj kvotoj (precipe pro la novaj limigoj de GitLab ), ĉiam indas kontroli la grandecon de la historio de viaj deponejoj kaj purigi ilin se necese.:
| GitHub Senpaga | GitLab Senpaga | |
| Maksimuma dosiera grandeco limo | 100MB | ∞ |
| Maksimuma repo-granda limo | 5.000 MB | ∞ |
| Maksimuma repo-nombra limo | ∞ | ∞ |
| Maksimuma totala limo | ∞ | 5.000 MB |
Fine, ankaŭ indas rigardi memgastigitan, senpagan varianton kiel Gitea ĵeti. Kun malmulte da peno vi povas sur a tre svelta servilo mem-gastigita Git-okazaĵo (GUI per SSL sekurigita, Sekurkopio inkluzivita, kontrolo super potenca API) gastiganto, kiuj ankaŭ estas bonegaj agordi kaj estas ankaŭ supera laŭ datuma protekto. Ĉi tie, cetere, vi ankaŭ povas uzi git-filter-repo Simple simpligu deponejojn:
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-repoJen specife la komando sudo -u git git gc --aggressive --prune=now grava (la krono kuras git gc alie havas tro longan pritondi tempon de 2 semajnoj).