git status-ը սողում է SSHFS-ի վրա VPN-ով. տեղափոխեք աշխատանքը

Պատճենեք 200 MB ֆայլ և այն թռչում է։ Այդ նույն պանակում գործարկեք git status և սպասումը բավական երկար է, որ ուշադրությունը փոխեք։ Այդ երկու դիտարկումները չեն հակասում, որովհետև զանգվածային փոխանցումը չափում է թողունակությունը, մինչդեռ Git-ը չափում է, թե վայրկյանում քանի փոքր հարցում կարող է ուղղել ֆայլային համակարգին, և կցված հեռավոր ծառը յուրաքանչյուր հարցում դարձնում է ետադարձ ուղևորություն։ VPN-ը լարելը չի ուղղի սխալ ձևված աշխատանքը։

Ինչու status-ը սխալ չափանիշ է

Git-ը պետք է տեղյակ լինի շատ ֆայլերի մասին՝ որոնք փոփոխված են, որոնք՝ չհետևված, և արդյոք քեշավորված ինդեքսի տվյալները դեռ համընկնում են սկավառակի վրա եղածի հետ։ SSHFS-ի վրայով այդ դիտարկումներից յուրաքանչյուրը կարող է ցանցային գործողություն լինել։ Աշխատանքի միավորը այստեղ ֆայլերի քանակն է, ոչ թե մեգաբայթերը։

Դրա համար է, որ կլոնից հետո առաջին status-ը դանդաղ է, և դրա համար է, որ հաջորդները կարող են ավելի դանդաղ լինել կառուցման արտածումով լի ծառում։ Չհետևված ֆայլերի սկանավորումն անցնում է պանակներով, որոնք գուցե ձեզ չեն հետաքրքրում, և յուրաքանչյուր քայլ ևս մեկ հարցում է կապի վրայով։ 40 ms ուղու վրա մի քանի հազար գրառում ունեցող ծառը դառնում է մի քանի հազար ետադարձ ուղևորություն։ Այդ թվաբանությունը հաստատելու համար փաթեթների որս անհրաժեշտ չէ։

Ներբեռնման չափանիշը ասում է, որ կապը լավ է; այն ոչինչ չի ասում, թե հազար փոքր ընթերցում այսօր կեսօրից հետո կավարտվի՞։

Տեղափոխեք աշխատանքային ծառը, ոչ թե կարգավորման կոճակները

Տեղական կլոնը աշխատանքային ծառը, ինդեքսը և Git-ի գործողությունները դնում է նույն մեքենայի վրա։ Pull-ը դառնում է տեսանելի ցանցային քայլ՝ փոխարենը յուրաքանչյուր ֆայլի ստուգում այդպիսին լինելու։

Սա հարմար է ամեն անգամ, երբ մշակողը կարող է անհրաժեշտ աղբյուրը պահել տեղում, ինչը հիմնականում այդպես է։ Այն նաև սրում է commit-ի և տեղակայման սահմանը, որովհետև տեղական ֆայլ խմբագրելն այլևս պատահաբար չի փոխում աշխատող հեռավոր ծառայությունը; փոփոխությունը պետք է push արվի և տեղակայվի, ինչպես ամեն ինչ։ Գինը այն է, որ կոդը գոյություն ունի երկու տեղում, ուստի որոշեք, թե որ պատճենն է հեղինակավոր և ինչպես է սերվերի շտապ ուղղումը վերադառնում պահոց։ Այդ զրույցն ավելի էժան է, քան status հրամանը, որը ոչ ոք չի ուզում գործարկել։

Եթե աշխատանքային տարածքը պետք է մնա հեռավոր, Git-ը գործարկեք այնտեղ

Երբեմն աշխատանքային տարածքը հնարավոր չէ տեղափոխել՝ կառուցումը պահանջում է այդ միջավայրը, տվյալները չափազանց մեծ են, կամ քաղաքականությունը աղբյուրը պահում է հոսթի վրա։ Այդ դեպքում գործարկեք Git-ը և համապատասխան մշակման գործիքները ֆայլերի կողքին՝ հաստատված հեռավոր shell-ի կամ հեռավոր մշակման միջավայրի միջոցով։ Խմբագրիչը կարող է մնալ նոթբուքի վրա, մինչ նրա backend-ը աշխատում է աշխատանքային ծառի կողքին։

Թանկ գործողությունները հետո կատարվում են տեղում՝ հեռավոր հոսթի վրա, և ցանցը կրում է խմբագրիչի երթևեկությունը հազարավոր stat կանչերի փոխարեն։ Սա նույն վերանորոգումն է, ինչ տեղական կլոնը՝ արտահայտված որպես տեղակայման ընտրություն, ոչ թե միգրացիա։

Համաժամեցումը սեփականատերերով աշխատահոսք է, ոչ թե քեշ

Համաժամեցված աշխատանքային տարածքը կարող է կրճատել կրկնվող հեռավոր ընթերցումները, բայց այն թափանցիկ քեշ չէ։ Այն պահանջում է սեփականատեր յուրաքանչյուր փոփոխության համար, կանոն հակամարտությունների համար և համաձայնություն գեներացված ֆայլերի շուրջ, որոնք երկու կողմերն էլ իրենցն են համարում։ Առանց այդ կանոնների՝ դասավորությունը ստեղծում է տարաձայնություն, ոչ թե հարմարավետություն։

Երկկողմ համաժամեցուցիչն առանց դրանց ստեղծում է այլ խնդիր, քան լուծել էր, սովորաբար միաձուլում, որը ոչ ոք չի կարող վերագրել։ Խուսափեք մեկ ընդհանուր աշխատանքային ծառի վրա երկու Git պրոցես գործարկելուց, եթե չեք հասկանում, թե ինչպես են դրանք համաձայնեցվում։

Ապա լարեք, և SSH-ը պահեք ողջամիտ

Երբ դասավորությունը ճիշտ է, երկու կարգավորում փոխում է, թե քանի ֆայլի մասին Git-ը պետք է հարցնի՝ status.showUntrackedFiles և core.untrackedCache-ի հետևում գտնվող չհետևվածների քեշը։ Ոչ մեկը չի փոխում, թե որքան արժե յուրաքանչյուր հարցումը 40 ms-ի ընթացքում; նրանք փոխում են միայն հարցումների քանակը։ Կոճակը պտտեք միայն այն ժամանակ, երբ ետադարձ ուղևորությունները տեղական են։

Չափեք այն հրամանի ժամանակը, որը ձեզ նյարդայնացնում է, փոխարենը մեկ մեծ ֆայլ պատճենող չափանիշից դատելու, և թողեք աջակցվող SSH գաղտնագրումը հանգիստ։ Հնացած ծածկագիրը չի կրճատում ետադարձ ուղևորությունը; այն ավելացնում է երկրորդ խնդիր, որն ապրում է առաջինից ավելի երկար։ git status-ի տեղեկանքը արժե մեկ ընթերցում, որովհետև հրամանը շատ ավելի շատ աշխատանք է կատարում, քան ենթադրում է նրա անունը։