Копирајте датотека од 200 MB и таа лета. Стартувајте git status во истиот директориум и чекањето е доволно долго за да се префрлите на нешто друго. Овие две набљудувања не се противречат, бидејќи масовниот пренос мери пропусност, додека Git мери колку мали прашања до датотечниот систем може да постави во секунда, и монтираното далечинско дрво го претвора секое прашање во повратно патување. Прилагодувањето на VPN нема да поправи погрешно обликуван товар.

Зошто status е погрешна мерка

Git мора да знае за многу датотеки: кои се изменети, кои не се следени и дали кешираните индекси сѐ уште одговараат на она што е на дискот. Преку SSHFS секое од тие набљудувања може да биде мрежна операција. Единицата работа овде е бројот на датотеки, не мегабајтите.

Затоа првиот status по клонирањето е бавен, и затоа следните можат да бидат уште побавни во дрво полно со излез од градење. Скенирањето на неследените поминува низ директориуми што можеби не ве интересираат, и секој чекор е уште едно барање преку врската. На пат од 40 ms дрво со неколку илјади записи станува неколку илјади повратни патувања. Не е потребно фаќање пакети за да се потврди таа аритметика.

Мерката за преземање ви кажува дека врската е добра; таа не кажува ништо за тоа дали илјада мали читања ќе завршат денес попладне.

Преместете го работното дрво, не копчињата за прилагодување

Локалниот клон ги става работното дрво, индексот и Git операциите на истата машина. Pull станува видлив мрежен чекор наместо секоја проверка на датотека.

Ова одговара секогаш кога развивачот може да го чува потребниот извор локално, а тоа е најчесто. Тоа ја изострува и границата меѓу commit и распоредување, бидејќи уредувањето на локална датотека повеќе не менува случајно далечинска услуга што работи; промената мора да се push-не и распореди како сѐ друго. Цената е што кодот постои на две места, затоа одлучете која копија е меродавна и како брза поправка на серверот се враќа во складиштето. Тој разговор е поевтин од status команда што никој не сака да ја стартува.

Ако работниот простор мора да остане далечински, стартувајте Git таму

Понекогаш работниот простор не може да се премести: градењето бара таа околина, податоците се преголеми или политиката го држи изворот на домаќинот. Тогаш стартувајте Git и соодветните развојни алатки покрај датотеките, преку одобрена далечинска школка или далечинска развојна околина. Уредувачот може да остане на преносниот сметач додека неговиот backend работи покрај работното дрво.

Скапите операции тогаш се случуваат локално на далечинскиот домаќин, а мрежата носи сообраќај на уредувачот наместо илјадници stat повици. Тоа е истата поправка како локален клон, изразена како избор за распоредување, а не миграција.

Синхронизацијата е работен тек со сопственици, не кеш

Синхронизиран работен простор може да ги намали повторените далечински читања, но не е транспарентен кеш. Потребен му е сопственик за секоја промена, правило за конфликти и договор за генерираните датотеки што двете страни ги сметаат за свои. Без тие правила распоредот создава несогласување, а не удобност.

Двонасочен синхронизатор без нив создава друга задача од онаа што ја реши, обично спојување што никој не може да го припише. Избегнувајте стартување два Git процеса врз едно споделено работно дрво, освен ако не разбирате како се координираат.

Потоа прилагодете и држете го SSH разумно

Кога распоредот е правилен, две поставки менуваат за колку датотеки Git мора да праша: status.showUntrackedFiles и кешот на неследените зад core.untrackedCache. Ниту една не менува колку чини секое прашање преку 40 ms; тие менуваат само колку прашања има. Завртете копче само кога повратните патувања се локални.

Мерете го времето на командата што ве нервира наместо да заклучувате од мерка што копира една голема датотека, и оставете го поддржаното SSH шифрирање на мир. Застарен шифар не го скратува повратното патување; додава втор проблем што го надживува првиот. Референцата за git status вреди едно читање, бидејќи командата работи многу повеќе отколку што сугерира името.

Поврзани статии