VPN üzerinden SSHFS'te git status sürünüyor: işi taşıyın

200 MB'lık bir dosyayı kopyalayın, uçar. Aynı dizinde git status çalıştırın ve bekleme başka bir şeye geçecek kadar uzun olur. Bu iki gözlem çelişmez, çünkü toplu aktarım aktarım hızını ölçerken Git saniyede kaç küçük dosya sistemi sorusu sorabildiğini ölçer ve bağlanmış uzak bir ağaç her soruyu bir gidiş-dönüşe çevirir. VPN'i ayarlamak yanlış biçimlenmiş bir iş yükünü düzeltmez.

Neden status yanlış ölçüt

Git birçok dosyayı bilmek zorundadır: hangileri değişti, hangileri izlenmiyor ve önbellekteki dizin verileri disktekiyle hâlâ eşleşiyor mu. SSHFS üzerinden bu gözlemlerin her biri bir ağ işlemi olabilir. Buradaki iş birimi dosya sayısıdır, megabayt değil.

Bu yüzden bir klondan sonraki ilk status yavaştır ve bu yüzden derleme çıktısıyla dolu bir ağaçta sonrakiler daha da yavaş olabilir. İzlenmeyenlerin taranması umurunuzda olmayan dizinlerden geçer ve her adım bağlantı üzerinden bir istek daha demektir. 40 ms'lik bir yolda birkaç bin girdili ağaç birkaç bin gidiş-dönüşe dönüşür. Bu aritmetiği doğrulamak için paket yakalamaya gerek yok.

İndirme ölçütü bağlantının iyi olduğunu söyler; bin küçük okumanın bu öğleden sonra biteceği hakkında hiçbir şey söylemez.

Çalışma ağacını taşıyın, ayar düğmelerini değil

Yerel bir klon çalışma ağacını, dizini ve Git işlemlerini aynı makineye koyar. Pull görünür bir ağ adımı olur, her dosya denetimi değil.

Bu, geliştirici gerekli kaynağı yerelde tutabildiğinde uygundur ve çoğu zaman öyledir. Ayrıca commit ile dağıtım arasındaki sınırı keskinleştirir, çünkü yerel bir dosyayı düzenlemek artık çalışan uzak bir hizmeti kazara değiştirmez; değişikliğin diğer her şey gibi push edilip dağıtılması gerekir. Bedeli, kodun iki yerde bulunmasıdır; bu yüzden hangi kopyanın yetkili olduğuna ve sunucudaki acil düzeltmenin depoya nasıl döneceğine karar verin. O konuşma, kimsenin çalıştırmak istemediği bir status komutundan daha ucuzdur.

Çalışma alanı uzakta kalmalıysa Git'i orada çalıştırın

Bazen çalışma alanı taşınamaz: derleme o ortama ihtiyaç duyar, veriler çok büyüktür veya politika kaynağı ana makinede tutar. O zaman Git'i ve ilgili geliştirme araçlarını dosyaların yanında, onaylanmış bir uzak kabuk veya uzak geliştirme ortamı üzerinden çalıştırın. Düzenleyici dizüstünde kalabilir, arka ucu çalışma ağacının yanında çalışırken.

Pahalı işlemler o zaman uzak ana makinede yerel olarak gerçekleşir ve ağ, binlerce stat çağrısı yerine düzenleyici trafiğini taşır. Bu, yerel bir klonla aynı düzeltmedir; göç olarak değil dağıtım seçimi olarak ifade edilir.

Eşitleme sahipleri olan bir iş akışıdır, önbellek değil

Eşitlenmiş bir çalışma alanı yinelenen uzak okumaları azaltabilir ama saydam bir önbellek değildir. Her değişiklik için bir sahip, çakışmalar için bir kural ve iki tarafın da kendisinin saydığı üretilmiş dosyalar için bir anlaşma gerekir. Bu kurallar olmadan düzen, kolaylık yerine anlaşmazlık yaratır.

Onlar olmadan iki yönlü eşitleyici, çözdüğünden farklı bir sorun üretir, genellikle kimsenin atfedemediği bir birleştirme. Anlaşılmayan bir biçimde iki Git sürecini tek paylaşılan çalışma ağacında çalıştırmaktan kaçının.

Sonra ayarlayın ve SSH'ı makul tutun

Düzen doğru olduğunda iki ayar Git'in kaç dosya hakkında soru soracağını değiştirir: status.showUntrackedFiles ve core.untrackedCache arkasındaki izlenmeyen önbellek. Hiçbiri 40 ms boyunca her sorunun maliyetini değiştirmez; yalnızca soru sayısını değiştirirler. Düğmeyi ancak gidiş-dönüşler yerel olduğunda çevirin.

Sizi rahatsız eden komutun süresini ölçün, tek bir büyük dosyayı kopyalayan bir ölçütten akıl yürütmek yerine, ve desteklenen SSH şifrelemesini olduğu gibi bırakın. Eski bir şifre gidiş-dönüşü kısaltmaz; birinciden daha uzun yaşayan ikinci bir sorun ekler. git status başvurusu bir kez okumaya değer, çünkü komut adının ima ettiğinden çok daha fazla iş yapar.