git status sa plazí na SSHFS cez VPN: presuňte prácu

Skopírujte súbor s 200 MB a letí. Spustite git status v tom istom adresári a čakanie je dosť dlhé na to, aby ste sa venovali niečomu inému. Tie dve pozorovania si neodporujú, pretože hromadný prenos meria priepustnosť, kým Git meria, koľko malých otázok na súborový systém dokáže položiť za sekundu, a pripojený vzdialený strom mení každú otázku na obrátku. Ladenie VPN neopraví zle tvarovanú záťaž.

Prečo je status zlé meradlo

Git sa musí dozvedieť o mnohých súboroch: ktoré sú zmenené, ktoré nesledované a či údaje v keši indexu ešte zodpovedajú tomu, čo leží na disku. Cez SSHFS môže byť každé z týchto pozorovaní sieťová operácia. Jednotkou práce je tu počet súborov, nie megabajty.

Preto je prvý status po klone pomalý a preto môžu byť ďalšie ešte pomalšie v strome plnom výstupov zostavenia. Skenovanie nesledovaných prechádza adresármi, ktoré vás nemusia zaujímať, a každý krok je ďalšia požiadavka cez spojenie. Na ceste 40 ms sa strom s niekoľkými tisícmi položiek zmení na niekoľko tisíc obrátok. Na potvrdenie tejto aritmetiky nie je potrebné zachytávať pakety.

Test sťahovania vám povie, že spojenie je v poriadku; nič nehovorí o tom, či tisíc malých čítaní dnes popoludní skončí.

Presuňte pracovný strom, nie gombíky ladenia

Lokálny klon umiestňuje pracovný strom, index a operácie Gitu na ten istý stroj. Pull sa stane viditeľným sieťovým krokom namiesto toho, aby ním bolo každé overenie súboru.

Hodí sa to vždy, keď vývojár môže mať potrebný zdroj lokálne, čo je väčšinou. Zostruje to aj hranicu medzi commitom a nasadením, pretože úprava lokálneho súboru už omylom nemení bežiacu vzdialenú službu; zmena sa musí odoslať a nasadiť ako čokoľvek iné. Cenou je, že kód existuje na dvoch miestach, takže rozhodnite, ktorá kópia je záväzná a ako sa horúca oprava na serveri vráti do repozitára. Ten rozhovor je lacnejší než príkaz status, ktorý nikto nechce spúšťať.

Ak musí pracovný priestor zostať vzdialený, spúšťajte Git tam

Niekedy sa pracovný priestor presunúť nedá: zostavenie potrebuje to prostredie, dáta sú príliš veľké alebo politika drží zdroj na hostiteľovi. Potom spúšťajte Git a príslušné vývojové nástroje vedľa súborov, cez schválený vzdialený shell alebo prostredie vzdialeného vývoja. Editor môže zostať na notebooku, kým jeho backend pracuje vedľa pracovného stromu.

Drahé operácie sa potom odohrávajú lokálne na vzdialenom hostiteľovi a sieť prenáša prevádzku editora namiesto tisícov volaní stat. Je to tá istá oprava ako lokálny klon, vyjadrená ako voľba nasadenia, nie ako migrácia.

Synchronizácia je pracovný postup s vlastníkmi, nie keš

Synchronizovaný pracovný priestor môže obmedziť opakované vzdialené čítania, ale nie je to priehľadná keš. Potrebuje vlastníka každej zmeny, pravidlo pre konflikty a dohodu o generovaných súboroch, ktoré obe strany považujú za svoje. Bez tých pravidiel usporiadanie vytvára nezhodu, nie pohodlie.

Obojsmerný synchronizátor bez nich vytvára iný problém, než aký riešil, zvyčajne zlúčenie, ktoré nikto nedokáže pripísať. Vyhnite sa spúšťaniu dvoch procesov Gitu na jednom zdieľanom pracovnom strome, ak nerozumiete, ako sa koordinujú.

Potom laďte a udržujte SSH rozumné

Keď je usporiadanie správne, dve nastavenia menia, o koľkých súboroch sa Git musí pýtať: status.showUntrackedFiles a keš nesledovaných za core.untrackedCache. Ani jedno nemení cenu každej otázky cez 40 ms; menia len to, koľko otázok existuje. Gombíkom otáčajte až vtedy, keď sú obrátky lokálne.

Zmerajte čas príkazu, ktorý vás štve, namiesto usudzovania z testu, ktorý kopíruje jeden veľký súbor, a nechajte podporované šifrovanie SSH na pokoji. Zastaraná šifra neskracuje obrátku; pridáva druhý problém, ktorý prežije ten prvý. Referenčná príručka ku git status stojí za jedno prečítanie, pretože príkaz robí oveľa viac práce, než naznačuje jeho názov.