Git LFS: jinsi ya kuhifadhi faili kubwa kwenye hifadhi ya Git

Git LFS ni nini na kwa nini inahitajika

Git LFS (Large File Storage) ni nyongeza rasmi ya Git kwa kuhifadhi faili kubwa: video, michoro ya PSD, seti za data, mifano ya mitandao ya neva, mali za michezo. Badala ya faili lenyewe, commit inaingiza kielekezi cha maandishi cha takriban baiti 130, na maudhui yanaenda kwenye hifadhi tofauti ya LFS kwenye seva. Wakati wa checkout nyongeza inaweka faili halisi kwenye saraka ya kazi, kwa hiyo kwako kila kitu kinaonekana kama Git ya kawaida.

Tatizo ambalo git lfs inalitatua liko kwenye muundo wa Git wenyewe. Kila toleo la kila faili linabaki milele kwenye historia, na clone inapakua historia yote. Ukibadilisha video ya MB 200 mara kumi, hifadhi tayari ina takriban GB 2, na kila msanidi mpya anapakua matoleo yote kumi, hata kama anahitaji la mwisho pekee. Mbinu za kubana na delta zinazofanya kazi vizuri kwa maandishi, karibu hazisaidii kwenye faili za binary.

Kwa LFS, clone inapakua tu matoleo ya faili kubwa ya commit ya sasa. Matoleo ya zamani yanabaki kwenye seva na yanavutwa unapobadili kwenda commit ya zamani.

Git LFS inafanya kazi vipi ndani

Utaratibu umejengwa juu ya vichujio vya Git — clean na smudge. Unapofanya git add kwenye faili ambalo LFS inalifuatilia, kichujio cha clean kinaweka maudhui kwenye akiba ya ndani .git/lfs/objects na kupitisha kielekezi kwenye index. Wakati wa checkout, kichujio cha smudge kinafanya kinyume: kinatafuta kitu kwa hash kwenye akiba (au kukipakua kutoka seva) na kuandika faili halisi.

Kielekezi kinaonekana hivi:

version https://git-lfs.github.com/spec/v1
oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
size 209715200

Mistari mitatu: toleo la vipimo, SHA-256 ya maudhui na ukubwa kwa baiti. Hiki ndicho kinachohifadhiwa kwenye historia ya Git, ndiyo maana historia inabaki nyepesi. Wakati wa git push hook ya pre-push inafanya kazi: kwanza vitu vipya vinapakiwa kupitia API ya LFS, kisha commits zinatumwa kwa itifaki ya kawaida.

Faili gani zipelekwe LFS inaamuliwa na faili la .gitattributes kwenye mzizi wa hifadhi. Linawekwa commit pamoja na msimbo, kwa hiyo kanuni zinafanana kwa timu nzima.

Jinsi ya kusakinisha Git LFS

Kwenye Git for Windows nyongeza tayari imo kwenye kisakinishi. Kwenye macOS na Linux inasakinishwa kama kifurushi:

# macOS (Homebrew)
brew install git-lfs

# Debian / Ubuntu
sudo apt install git-lfs

# Fedora
sudo dnf install git-lfs

Baada ya usakinishaji, tekeleza mara moja kwa mtumiaji:

git lfs install

Amri hii inaandika vichujio vya LFS kwenye ~/.gitconfig ya kimataifa na kuweka hooks kwenye hifadhi ya sasa, ukiwa ndani yake. Kuthibitisha kwamba kila kitu kipo, tumia git lfs version, na usanidi wa kina (anwani ya seva, njia za akiba) unaonyeshwa na git lfs env.

Jinsi ya kuanza kufuatilia faili kubwa

Mfano wa kawaida kwa mradi mpya:

git lfs track "*.psd"
git lfs track "*.mp4"
git lfs track "models/**"

git add .gitattributes
git add design/banner.psd
git commit -m "Ongeza mchoro wa bango kupitia LFS"
git push origin main

Nukuu kuzunguka mfumo ni za lazima: bila hizo ganda litapanua *.psd kuwa orodha ya faili za folda ya sasa, na kanuni itakuwa si sahihi. Baada ya git lfs track, mstari huu unaonekana kwenye .gitattributes:

*.psd filter=lfs diff=lfs merge=lfs -text

Sifa -text inazima ubadilishaji wa mwisho wa mistari, ambao ungeharibu faili la binary. Mpangilio ni muhimu: kwanza kanuni ya track, kisha git add ya faili. Ikiwa faili lilikuwa limeongezwa kwa njia ya kawaida kabla kanuni haijawepo, lilibaki kwenye historia kama blob ya kawaida.

Jinsi ya kuhakiki kwamba faili liko kwenye LFS

git lfs ls-files
4d7a214614 * design/banner.psd
9c1e0b7a3f * video/intro.mp4

git lfs status

git lfs ls-files inaonyesha faili za commit ya sasa zilizo kwenye LFS. Nyota inamaanisha maudhui yamepakuliwa, kistari — kwamba kwenye nakala ya kazi kuna kielekezi tu. Orodha ya mifumo ya ufuatiliaji inatolewa na git lfs track bila hoja, na kanuni inaondolewa kwa git lfs untrack "*.psd".

Kunakili na kupata faili

Kawaida git clone inafanya kazi na LFS bila kuonekana: ikiwa nyongeza imewekwa, faili kubwa zinapakuliwa kiotomatiki. Lakini mwenzako asipokuwa na LFS, kwenye nakala yake ataona vielekezi vya maandishi badala ya picha — hii ndiyo dalili ya kawaida ya «kwangu badala ya PSD kuna maandishi». Tatizo linatatuliwa kwa usakinishaji na amri:

git lfs install
git lfs pull

git lfs pull inapakua vitu vya commit ya sasa na kuviweka kwenye saraka ya kazi. Kuna pia git lfs fetch — hiyo inapakua kwenye akiba tu bila kugusa faili. Ukiongeza --all, inapakua vitu vya marejeo yote, jambo muhimu kwa nakala kamili ya akiba au kuhamisha kwenda seva nyingine.

Jinsi ya kunakili bila faili kubwa

Kwenye CI au ukihitaji msimbo tu, kupakua GB za mali si lazima. Kigeu cha mazingira kinazima kichujio cha smudge:

GIT_LFS_SKIP_SMUDGE=1 git clone https://example.com/team/game.git
cd game
git lfs pull --include="textures/ui/**"

Hifadhi inanakiliwa ikiwa na vielekezi, kisha unachukua kwa kuchagua faili unazohitaji kwa --include (kuna pia --exclude). Hii inaharakisha sana ujenzi kwenye pipelines.

Jinsi ya kuhamisha faili zilizopo kwenda Git LFS

Hali ya kawaida: hifadhi tayari imevimba, faili kubwa zipo kwenye historia. Amri git lfs track haifanyi kazi kwa yaliyopita — inaathiri commits mpya tu. Ili kuandika upya historia, tumia git lfs migrate.

Kwanza pima kinachochukua nafasi:

git lfs migrate info --everything --top=10

Kisha hamisha aina zinazohitajika kwenye matawi yote:

git lfs migrate import --include="*.psd,*.mp4" --everything
git push --force --all
git push --force --tags

Uhamisho unaandika upya kila commit ambapo faili hizo zilionekana, kwa hiyo hash zote zinabadilika. Ni hadithi ile ile ya rebase kwenye matawi yaliyochapishwa: washiriki wote lazima waarifiwe, na baada ya force push wanapaswa kunakili hifadhi upya au kuweka upya matawi yao kwa nguvu. Kabla ya uhamisho fanya nakala ya akiba (git clone --mirror).

Ikiwa historia haiwezi kuandikwa upya, kuna chaguo laini: git lfs migrate import --no-rewrite njia/ya/faili. Inaunda commit mpya inayobadilisha faili kuwa LFS kuanzia sasa. Matoleo ya zamani yanabaki kwenye historia, lakini ukuaji wa hifadhi unasimama.

Kufunga faili: ulinzi dhidi ya migongano kwenye binaries

Wabunifu wawili wanabadilisha PSD moja — na Git haiwezi kuunganisha mabadiliko yao, kazi ya mmoja itapotea. Kwa faili kama hizi LFS ina kufunga (locks). Unaweka aina kama inayoweza kufungwa:

git lfs track "*.psd" --lockable

Sifa lockable itaongezwa kwenye .gitattributes, na faili kama hizo kwenye nakala ya kazi zitakuwa za kusoma tu hadi uzifunge:

git lfs lock design/banner.psd
git lfs locks
design/banner.psd	anna	ID:123

# baada ya push ya mabadiliko
git lfs unlock design/banner.psd

Wakati faili limefungwa, push ya mabadiliko kutoka kwa mtu mwingine itakataliwa. Kufunga kunahitaji usaidizi wa seva, kwa hiyo kunafanya kazi kwenye majukwaa makubwa ya Git, lakini kwenye seva ya kujitengenezea huenda isipatikane. Msimamizi anaweza kuondoa kufunga cha mtu mwingine kwa git lfs unlock --force.

Vitu vya LFS vinakaa wapi na vinagharimu kiasi gani

Vitu vya LFS vinaishi kwenye seva inayounga mkono API ya LFS. Majukwaa maarufu ya Git na suluhisho za kujiendesha (self-hosted) zinaitoa, pamoja na seva tofauti. Majukwaa ya wingu yana mipaka ya nafasi na trafiki ya LFS, na mipaka hiyo inatofautiana kati ya huduma na mipango — hakiki masharti ya sasa ya jukwaa lako kabla ya kuweka humo seti za data za mamia ya GB.

Kumbuka kwamba trafiki inahesabiwa kila upakuaji: CI inayonakili hifadhi yenye faili za LFS kwa kila commit inaweza kumaliza kikomo haraka kuliko binadamu. Hifadhi .git/lfs kati ya ujenzi au tumia GIT_LFS_SKIP_SMUDGE.

Akiba ya ndani nayo inakua. Amri git lfs prune inafuta vitu vya zamani ambavyo tayari viko kwenye seva na havihitajiki kwa commits za sasa na za hivi karibuni.

Git LFS inafaa lini na haifai lini

Makosa ya kawaida na jinsi ya kuyarekebisha

Kwenye nakala ya kazi badala ya faili kuna kielekezi cha maandishi

LFS haijasakinishwa, au clone ilifanywa kwa GIT_LFS_SKIP_SMUDGE=1. Tekeleza git lfs install kisha git lfs pull.

Faili liliingia kwenye historia bila LFS

Kanuni ya track iliongezwa baada ya git add. Ikiwa commit bado haijatumwa, ondoa faili kwenye index (git rm --cached faili), hakikisha kanuni ipo kwenye .gitattributes, kisha uliongeze tena. Ikiwa tayari limetumwa — git lfs migrate import. Kutafuta faili kama hayo kunasaidiwa na git lfs fsck --pointers.

Push inakataliwa kwa sababu ya ukubwa wa faili

Majukwaa mengi yanaweka kikomo cha ukubwa wa kitu kimoja kwenye Git ya kawaida. Ujumbe kama «this exceeds the file size limit» unamaanisha faili lilipaswa kwenda LFS. Andika upya commit ya mwisho au historia, kama ilivyoelezwa hapo juu — commit rahisi ya «futa faili» haitasaidia, kwani faili litabaki kwenye commits zilizotangulia.

Baada ya git lfs migrate, kwa wenzako kila kitu kimeharibika

Matawi yao ya ndani yanategemea hash za zamani. Njia salama zaidi ni kunakili hifadhi upya; ikiwa kuna kazi ambayo haijatumwa, ihamishe kwa cherry-pick kwenye matawi mapya.

Karatasi ya kudanganya ya amri za Git LFS

Muhtasari

Git LFS inatoa faili kubwa za binary kutoka historia na kuziweka kwenye hifadhi tofauti, ikiacha kwenye commits vielekezi vyepesi. Kanuni kuu ni kusanidi git lfs track kabla ya commit ya kwanza ya faili kubwa, kuweka .gitattributes kwenye commit na kufuatilia kikomo cha jukwaa lako. Ikiwa faili tayari ziko kwenye historia, git lfs migrate inasaidia, lakini ni kuandika upya historia pamoja na matokeo yake yote. Kazi na historia, rebase na zana nyingine za juu za Git tunazifafanua kwa vitendo katika kozi ya Git.