Մաքրել Git-ի պատմությունը մաս 208
22

Զգայուն տվյալներ կամ հիշողության չափազանց մեծ սպառում. Git պատմությունը փոխելու լավ պատճառներ կան: Այս բլոգային գրառման մեջ ես բացատրեցի, թե ինչպես կարելի է մաքրել ֆայլերը Git պատմությունից՝ օգտագործելով BFG : BFG-ի թույլ կետը ուղիղ ուղիների աջակցության բացակայությունն է, այնպես որ դուք չեք կարող պատմությունից հատուկ հեռացնել ֆայլերը կամ ենթաթղթապանակների թղթապանակները: Դրանով իսկ ժամանակն է այլընտրանքային լուծումներ փնտրելու։

---

Բացի պաշտոնապես չառաջարկվող git ֆիլտրի ճյուղից , git-filter-repo- ն պատմությունը մաքրելու գործիքներից մեկն է : Կարճ տեղադրումից հետո մենք նախ վերլուծում ենք պահեստը և գտնում, օրինակ, պատմության մեջ ամենամեծ թղթապանակները:

git filter-repo --analyze

Դե եղեք թղթապանակում .git/filter-repo/analysis ստեղծել է բոլոր տեսակի TXT ֆայլեր:

• directories-all-sizes.txt
• extensions-all-sizes.txt
• path-all-sizes.txt
• ...

Արժե ֆայլը directories-all-sizes.txt ավելի ուշադիր նայեք:

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

...

Հաճախ է պատահում, որ դուք երկար ժամանակ անտեսել և հեռացնել եք պատմության HEAD տվյալները (օրինակ՝ WordPress մեդիա պանակը wp-content/uploads/ կամ պատահաբար հրված մեկը node_modules- կամ vendor- Ամրակ):

Ընդհանուր առմամբ խորհուրդ է տալիս git-filter-repo մաքրումից հետո՝ մղելով նոր, դատարկ պահեստ: Այստեղ թվարկված են բազմաթիվ պատճառներ, ինչու դա իմաստ ունի և խուսափում է բազմաթիվ խնդիրներից: Այնուամենայնիվ, կարող է պատահել, որ դուք ցանկանում եք մղել նույն պահոցը, և դա հնարավոր է նաև մի քանի հուշումներով:

Կարևոր է, կոդի հոստինգի հիմնական հարթակները GitHub և GitLab առաջարկել տարբեր մոտեցումներ, որոնցից մի քանիսը տարբերվում են միմյանցից: Օրինակ, GitHub-ում մենք հեռացնում ենք wp-content/uploads/ օգտագործելով հետևյալ քայլերը git-filter-repo պատմությունից:

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

Այժմ մենք կարող ենք նաև չափը ստուգել հեռակա կարգով (API-ի և UI-ի միջոցով չափը փոխելը կարող է տևել մինչև 24 ժամ): Դա անելու համար բացեք պահեստի կարգավորումները (եթե պահեստը պատկանում է կազմակերպությանը, նախ պետք է ձեր սեփական հաշիվը ավելացնեք կազմակերպությանը): Այժմ մենք տեսնում ենք չափը:

Գործընթացը փոքր-ինչ տարբերվում է 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

Հերթական ~5 րոպե սպասելուց հետո մենք կարող ենք անցնել տակը Settings > Usage Quotas դիտել պահեստային տարածքը:

Հեռացումից հետո կարևոր է, որ ներգրավված բոլոր ծրագրավորողները ներգրավված լինեն վերջին քայլերում. Եթե օգտատերն այժմ նորմալ մղում է կատարում իր սեփական տեղական պատճենով, դա կհանգեցնի նրան, որ մեծ ֆայլերը կվերադարձնեն կենտրոնական պահեստ: Ուստի առաջարկվում են հետևյալ 3 տարբերակները:

• "խեղճ մարդու թարմ կլոնը"
  • rm -rf .git && git clone xxx temp && mv temp/.git ./.git && rm -rf temp
  • Փոփոխված ֆայլերի համար (կախված հավելվածից): git checkout -- . կամ. git add -A . && git commit -m "Push obscure file changes." && git push
• "սկսել զրոյից"
  • rm -rf repo && git clone xxx .
• «տգեղ ձգում ռեբեյզով»
  • git pull -r
  • Այստեղ դուք դեռևս ունեք չմաքրված պատմություն, բայց շատ դեպքերում դուք այլևս պատահաբար չեք վերագրում հեռավոր պահեստը մեծ տեղական տարբերակով

Ընթացիկ քվոտաների ընթացքում (հատկապես GitLab-ի նոր սահմանափակումների պատճառով ) միշտ արժե ստուգել ձեր պահեստների պատմության չափը և անհրաժեշտության դեպքում մաքրել դրանք։:

	GitHub անվճար	GitLab անվճար
Ֆայլի առավելագույն չափի սահմանափակում	100 ՄԲ	∞
Առավելագույն ռեպո չափի սահմանափակում	5000 ՄԲ	∞
Առավելագույն ռեպո քանակի սահմանաչափ	∞	∞
Ընդհանուր չափի առավելագույն սահմանաչափ	∞	5000 ՄԲ

Վերջապես, արժե նաև դիտել ինքնուրույն, անվճար տարբերակ, ինչպիսին է Գիտեա նետել. Փոքր ջանքերով դուք կարող եք մի շատ բարակ սերվեր ինքնակառավարվող Git օրինակ (GUI ըստ SSL ապահովված, Կրկնօրինակում ներառված, վերահսկողություն հզոր API) հյուրընկալող, որոնք նույնպես գերազանց են կարգավորել և գերազանցում է նաև տվյալների պաշտպանության առումով: Այստեղ, ի դեպ, կարող եք նաև օգտագործել git-filter-repo Պարզապես շտկեք պահեստները:

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

Ահա, մասնավորապես, հրամանը sudo -u git git gc --aggressive --prune=now կարևոր (քրոնիկ վազում git gc հակառակ դեպքում ունի մեկը չափազանց երկար էտելու ժամանակը 2 շաբաթ):