git status ryömii SSHFS:llä VPN:n yli: siirrä työ

Kopioi 200 MB:n tiedosto, ja se lentää. Aja git status samassa hakemistossa, ja odotus on tarpeeksi pitkä, että ehtii ajatella muuta. Nämä kaksi havaintoa eivät ole ristiriidassa, koska massansiirto mittaa läpimenoa, kun taas Git mittaa, kuinka monta pientä tiedostojärjestelmäkysymystä se voi esittää sekunnissa, ja liitetty etäpuu muuttaa jokaisen kysymyksen edestakaiseksi matkaksi. VPN:n virittäminen ei korjaa väärin muotoiltua kuormaa.

Miksi status on väärä mittari

Gitin on tiedettävä monista tiedostoista: mitkä ovat muuttuneet, mitkä seuraamattomia ja vastaavatko välimuistiin tallennetut indeksitiedot yhä sitä, mitä levyllä on. SSHFS:n yli jokainen näistä havainnoista voi olla verkkotoiminto. Työn yksikkö on tässä tiedostojen määrä, ei megatavut.

Siksi ensimmäinen status kloonin jälkeen on hidas, ja siksi myöhemmät voivat olla vielä hitaampia puussa, joka on täynnä build-tulostetta. Seuraamattomien skannaus kulkee hakemistoissa, joista et ehkä välitä, ja jokainen askel on uusi pyyntö yhteyden yli. 40 ms:n polulla puusta, jossa on muutama tuhat merkintää, tulee muutama tuhat edestakaista matkaa. Tämän aritmetiikan vahvistamiseen ei tarvita pakettikaappausta.

Latausmittari kertoo, että yhteys on kunnossa; se ei kerro mitään siitä, ehtiikö tuhat pientä lukua valmiiksi tänä iltapäivänä.

Siirrä työpuu, älä säätönuppeja

Paikallinen klooni laittaa työpuun, indeksin ja Gitin toiminnot samaan koneeseen. Pullista tulee näkyvä verkkovaihe sen sijaan, että jokaisesta tiedostotarkistuksesta tulisi sellainen.

Tämä sopii aina, kun kehittäjä voi pitää tarvittavan lähdekoodin paikallisesti, ja niin on useimmiten. Se terävöittää myös commitin ja käyttöönoton rajaa, koska paikallisen tiedoston muokkaaminen ei enää vahingossa muuta käynnissä olevaa etäpalvelua; muutos on työnnettävä ja otettava käyttöön kuin mikä tahansa muu. Hinta on, että koodi on kahdessa paikassa, joten päätä, kumpi kopio on valtuutettu ja miten palvelimen pikakorjaus palaa repositorioon. Se keskustelu on halvempi kuin status-komento, jota kukaan ei halua ajaa.

Jos työtilan on pysyttävä etänä, aja Git siellä

Joskus työtilaa ei voi siirtää: build tarvitsee sen ympäristön, data on liian suurta tai käytäntö pitää lähteen isännässä. Silloin aja Git ja asiaankuuluvat kehitystyökalut tiedostojen vieressä, hyväksytyn etäkuoren tai etäkehitysympäristön kautta. Editori voi jäädä kannettavaan, kun sen taustaosa työskentelee työpuun vieressä.

Kalliit toiminnot tapahtuvat silloin paikallisesti etäisännässä, ja verkko kantaa editorin liikennettä tuhansien stat-kutsujen sijaan. Se on sama korjaus kuin paikallinen klooni, ilmaistuna käyttöönoton valintana eikä migraationa.

Synkronointi on työnkulku, jolla on omistajat, ei välimuisti

Synkronoitu työtila voi vähentää toistuvia etälukuja, mutta se ei ole läpinäkyvä välimuisti. Se tarvitsee omistajan jokaiselle muutokselle, säännön ristiriidoille ja sopimuksen luoduista tiedostoista, jotka molemmat osapuolet uskovat omistavansa. Ilman näitä sääntöjä järjestely luo eripuraa eikä mukavuutta.

Kaksisuuntainen synkronointi ilman niitä tuottaa eri ongelman kuin se ratkaisi, yleensä yhdistämisen, jota kukaan ei osaa kohdistaa. Vältä kahden Git-prosessin ajamista yhtä jaettua työpuuta vasten, ellet ymmärrä, miten ne koordinoivat.

Viritä sitten, ja pidä SSH järkevänä

Kun järjestely on oikein, kaksi asetusta muuttaa sitä, kuinka monesta tiedostosta Gitin on kysyttävä: status.showUntrackedFiles ja seuraamattomien välimuisti core.untrackedCache:n takana. Kumpikaan ei muuta sitä, mitä jokainen kysymys maksaa 40 ms:n yli; ne muuttavat vain kysymysten määrää. Käännä nuppia vasta, kun edestakaiset matkat ovat paikallisia.

Mittaa sen komennon aika, joka ärsyttää sinua, sen sijaan että päättelet mittarista, joka kopioi yhden ison tiedoston, ja jätä tuettu SSH-salaus rauhaan. Vanhentunut salaus ei lyhennä edestakaista matkaa; se lisää toisen ongelman, joka elää ensimmäistä pidempään. Git status -viite on yhden lukukerran arvoinen, koska komento tekee paljon enemmän työtä kuin nimensä antaa ymmärtää.