git status пълзи по SSHFS през VPN: преместете работата
Голям файл се копира бързо, а git status пълзи. Ако дървото е на SSHFS през VPN, цената са обръщания на файл, не честотната лента. Преместете работата.
Копирайте файл от 200 MB и той лети. Пуснете git status в същата папка и изчакването е достатъчно дълго, за да превключите на друга задача. Тези две наблюдения не си противоречат, защото обемният трансфер измерва пропускателната способност, а Git измерва колко малки въпроса към файловата система може да зададе за секунда, и монтираното отдалечено дърво превръща всеки въпрос в обръщане. Настройването на VPN няма да поправи натоварване с грешна форма.
Защо status е грешният ориентир
Git трябва да научи за много файлове: кои са променени, кои не са проследени и дали кешираните данни на индекса още съвпадат с това, което е на диска. През SSHFS всяко от тези наблюдения може да е мрежова операция. Единицата работа тук е броят файлове, а не мегабайтите.
Затова първият status след клониране е бавен и затова следващите може да са още по-бавни в дърво, пълно с изход от компилация. Сканирането за непроследени файлове обхожда папки, които може да не ви интересуват, и всяка стъпка е още една заявка през връзката. При път от 40 ms дърво с няколко хиляди записа става няколко хиляди обръщания. Не е нужен прехват на пакети, за да потвърдите тази аритметика.
Тестът за изтегляне казва, че връзката е добра; той не казва нищо за това дали хиляда малки четения ще завършат днес следобед.
Преместете работното дърво, не копчетата за настройка
Локалното клониране поставя работното дърво, индекса и операциите на Git на една и съща машина. Pull става видима мрежова стъпка, вместо всяка проверка на файл да става такава.
Това пасва винаги когато разработчикът може да държи нужния източник локално, а това е в повечето случаи. Освен това изостря границата между commit и внедряване, защото редактирането на локален файл вече не променя случайно работеща отдалечена услуга; промяната трябва да се избута и внедри като всичко останало. Разменната монета е, че кодът съществува на две места, затова решете кое копие е меродавно и как бърза поправка на сървъра се връща в хранилището. Този разговор е по-евтин от команда status, която никой не иска да пусне.
Ако работното пространство трябва да остане отдалечено, пуснете Git там
Понякога работното пространство не може да се премести: компилацията се нуждае от тази среда, данните са твърде големи или политиката държи източника на хоста. Тогава пуснете Git и подходящите инструменти за разработка до файловете, през одобрен отдалечен shell или среда за отдалечена разработка. Редакторът може да остане на лаптопа, докато неговият бекенд работи до работното дърво.
Скъпите операции тогава се случват локално на отдалечения хост, а мрежата носи трафика на редактора вместо хиляди stat извиквания. Това е същата поправка като локалното клониране, изразена като избор за внедряване, а не като миграция.
Синхронизацията е работен процес със собственици, не кеш
Синхронизираното работно пространство може да намали повтарящите се отдалечени четения, но то не е прозрачен кеш. Нуждае се от собственик за всяка промяна, правило за конфликти и споразумение за генерираните файлове, които и двете страни смятат за свои. Без тези правила подредбата създава несъгласие, а не удобство.
Двупосочен синхронизатор без тях създава различен проблем от решението, обикновено сливане, което никой не може да припише. Избягвайте да пускате два процеса Git върху едно споделено работно дърво, освен ако не разбирате как се координират.
След това настройте и пазете SSH разумен
След като подредбата е вярна, две настройки променят за колко файла Git трябва да пита: status.showUntrackedFiles и кешът за непроследени зад core.untrackedCache. Нито една не променя цената на всеки въпрос при 40 ms; те променят само колко въпроса има. Завъртете копче едва когато обръщанията са локални.
Измерете времето на командата, която ви дразни, вместо да разсъждавате от тест, който копира един голям файл, и оставете поддържаното SSH шифроване на мира. Остарелият шифър не скъсява обръщане; той добавя втори проблем, който надживява първия. Справочникът за git status заслужава едно четене, защото командата върши много повече работа, отколкото името ѝ подсказва.