10.7 Гит изнутра - Одржавање и опоравак податак

Програм Гит повремен о аутоматски покреће команду која се зове „auto gc”. Ова команда најчешће не ради ништа. Међутим, када има превише слободних објеката (оних који се не налазе у pack фајлу) или превише pack фајлова, програм Гит покреће темељну git gc команду. Овде „gc” замењује garbage collect (скупљање отпада) и та команда обавља више ствари: скупља се слободне објекте и поставља их у pack фајлове, консолидује pack фајлове у један велики pack фајл и уклања објекте до којих не може да се стигне из ниједног комита, а стари су барем неколико месеци.

Команду auto gc можете и ручно да покренете на следећи начин:

Да поновимо, ово у општем случају не ради ништа. Морате имати око 7.000 слободних објеката, или више од 50 pack фајлова да би програм Гит покренуо праву gc команду. Ове границе можете променити конфигурационим подешавањима gc.auto и gc.autopacklimit респективно.

Друга ствар коју ће gc урадити је да ваше референце спакује у један фајл. Претпоставимо да репозиторијум садржи следеће гране и ознаке:

Ако извршите git gc, више нећете имати ове фајлове у refs директоријуму. Програм Гит ће их у циљу ефикасности преместити у фајл под именом .git/packed-refs који изгледа овако:

Ако ажурирате референцу, програм Гит не уређује овај фајл, већ уписује нови фајл у refs/heads. Да би за дату референцу дошао до одговарајуће SHA-1 вредности, програм Гит тражи ту референцу у refs директоријуму, па онда проверава packed-refs фајл. Тако да ако референцу не нађе у refs директоријуму, она се највероватније налази у вашем packed-refs фајлу.

Приметите последњу линију фајла која почиње са ^. То значи да је ознака непосредно изнад обележена ознака и да је та линија комит на коју показује обележена ознака.

У неком тренутку током вашег Гит пута, можете грешком да изгубите комит. У општем случају, ово се дешава јер сте насилно обрисали грану на којој се налазио рад, а испоставља се да вам је грана ипак била потребна; ули урадите hard-reset гране, чиме напуштате комитове из којих сте нешто хтели. Под претпоставком да се то догодило, постоји ли начин да комитове вратите?

Ево примера коју ради hard-reset master вашег тест репозиторијума на старији комит, па онда опоравља изгубљене комитове. Најпре, хајде да погледамо стање вашег репозиторијума у овом тренутку:

Померимо сада master грану на средњи комит:

Ефективно сте изгубили горња два комита – немате више грану из које се може стићи у те комитове. Морате да пронађете SHA-1 последњег комита, па да додате грану која показује на њега. Трик је пронаћи тај SHA-1 последњег комита – не сећате се баш како се то ради, зар не?

Често је најбржи начин да се употреби алат који се зове git reflog. Док радите, програм Гит у тишини чува шта је ваш HEAD сваки пут када га измените. Сваки пут када комитујете или пређете на другу грану, ажурира се reflog. Reflog се такође ажурира командом git update-ref и то је још један разлога да корисите њу, уместо да једноставно уписујете SHA-1 вредност у своје ref фајлове, као што смо показали у Гит референце. Ако извршите git reflog, видећете где сте се налазили у било које време:

Овде можемо видети два комита које смо одјавили, међутим нема много детаља. Ако желите да исте информације видите на много кориснији начин, треба да извршите git log -g, што вам приказује уобичајени лог излаз за ваш reflog.

Изгледа да је комит на дну онај који сте изгубили, тако да га опорављате креирајући нову грану на том комиту. На пример, на том комиту (ab1afef) можете да започнете нову грану са именом recover-branch:

Фино – сада имате грану која се зове recover-branch на оном месту на којем се налазила ваша master грана, чиме поново може да се дође до прва два комита. Даље, претпоставимо да се из неког разлога ваш губитак не налази у reflog – то може да се симулира уклањањем recover-branch гране и брисањем reflog. Сада ништа не може да дође до прва два комита:

Пошто се reflog подаци чувају у .git/logs/ директоријуму, ефективно више немате reflog. Како сада да вратите те комитове? Један начин је да употребите алат git fsck који проверава интегритет базе података. Ако га покренете са опцијом --full, он вам приказује све објекте на које не указује ниједан други објекат:

У овом случају, ваш комит који недостаје видите иза стринга „dangling commit”. Можете да га опоравите на исти начин, додавањем гране која показује на тај SHA-1.

Постоји много одличних ствари у вези програма Гит, али једна од могућности која може да буде узрок проблема је чињеница да git clone преузима целокупну историју пројекта, укључујући сваку верзију сваког фајла. Ово није тако лоше ако је у репозиторијуму само изворни кôд, јер је програм Гит одлично оптимизован да ефикасно компресује податке. Међутим, ако је неко у неком тренутку историје вашег пројекта додао један огроман фајл, свако клонирање ће увек бити принуђено да преузима тај велики фајл, чак и ако је одмах био уклоњен у наредном комиту. Пошто до њега може да се стигне из историје, он ће тамо заувек да остане.

Ово може да представља велики проблем када Subversion или Перфорс репозиторијуме конвертујете у Гит. Пошто у тим системима не преузимате комплетну историју, ова врста додавања има мало последица. Ако сте обавили увоз из неког другога система, или откријете да вам је репозиторијум много већи него што би требало да буде, ево начина на који можете да пронађете и уклоните велике објекте.

Упозоравамо вас: ова техника може да оштети вашу историју комитова. Она поново исписује сваки комит објекат почевши од најранијег стабла које морате да измените како би уклонили референцу на велики фајл. Ако то урадите непосредно након увоза, пре него што је било ко свој рад почео да базира на комиту, онда нема проблема – у супротном, све сараднике морате обавестити да свој рад морају ребазирати преко ваших нових комитова.

Да бисмо показали ово, додаћете велики фајл у свој тест репозиторијум, уклонићете га у наредном комиту, пронаћи га и трајно уклонити из репозиторијума. Најпре, додајте велики објекат у своју историју:

Ууупс – нисте хтели да у свој пројекат додате огромну tarball архиву. Боље да је се решите:

А сада, извршите gc над својом базом да видите колико простора заузима:

Можете да извршите и команду count-objects да брзо погледате колико простора се користи:

Ставка size-pack је величина ваших pack фајлова у килобајтима, тако да користите скоро 5МБ. Пре последњег комита, трошило се близу 2K – очито, уклањање фајла из претходног комита га није уклонило из историје. Сваки пут када неко клонира овај репозиторијум, мораће да клонирају свих 5МБ само да би преузели овај малецки пројекат, јер сге грешком додали велики фајл. Хајде да га се решимо.

Најпре морате да га пронађете. У овом случају већ знате који је то фајл. Али претпоставимо да не знате; како можете да откријете који фајл или фајлови заузимају толики простор? Ако извршите git gc, сви објекти се налазе у pack фајлу; велике објекте можете да препознате извршавањем друге водоводне команде која се зове git verify-pack и сортирањем по трећем пољу излаза, које представља величину. Такође можете и да преусмерите излаз кроз команду tail јер вас интересује само неколико највећих фајлова на крају:

Велики објекат је на дну: 5МБ. Да бисте пронашли у ком фајлу се налази, употребићете команду rev-list коју сте накратко употребили у Спровођење одређеног формата за комит поруке. Ако команди rev-list проследите --objects, она ће приказати све SHA-1 вредности комитова заједно са придруженим путањама фајлова. Да бисте пронашли име вашег блоба, употребите следеће:

Сада треба да уклоните овај фајл из свих стабала у вашој прошлости. Лако можете да видите који комитови су мењали овај фајл:

Да бисте овај фајлу потпуно уклонили из Гит историје, морате поново да испишете све комитове низводно од 7b30847. За то ћете употребити команду filter-branch, коју сте већ користили у Поновно исписивање историје:

Опција --index-filter је слична опцији --tree-filter која је употребљена у Поновно исписивање историје, осим што уместо да прослеђивања команде која мења одјављене фајлове на диску, она сваки пут мења стејџ или индекс.

Уместо да одређени фајл уклоните са нечим као што је rm фајл, морате да га уклоните са git rm --cached – морате да га уклоните из индекса, а не са диска. Разлог због којег се овако ради је брзина – пошто програм Гит не мора да одјављује сваку ревизију на диск пре него што изврши ваш филтер, процес може да буде много, много бржи. Ако желите, исти задатак можете да извршите са --tree-filter. --ignore-unmatch опција команди git rm говори да не прекине извршавање са грешком ако не наиђе на шаблон који покушавате да уклоните. Коначно, тражите од команде filter-branch да поново испише вашу историју почевши од комита 7b30847 на овамо, јер знате да је проблем настао на том месту. У супротном, она ће да крене од почетак и без потребе ће продужити извршавање.

Ваш историја више нема референцу на тај фајл. Међутим, ваш reflog и нови скуп референци које је програм Гит додао када сте извршили filter-branch под .git/refs/original још увек садрже, тако их морате уклонити и препаковати базу података. Пре поновног паковања, морате да се решите свега што има показивач на те старе комитове:

Хајде да видимо колико простора сте уштедели.

Величина спакованог репозиторијума је спала на 8К, што је много боље од 5МБ. Из size вредности видите да се велики објекат још увек налази у слободним објектима, тако да није нестао; али се приликом гурања или накнадног клонирања неће преносити, а те јо оно што је битно. Ако то заиста желите, могли бисте потпуно да уклоните објекат ако извршите git prune са --expire опцијом: