git status روی SSHFS از طریق VPN کند می‌شود: کار را جابه‌جا کنید

یک فایل 200 MB را کپی کنید و پرواز می‌کند. در همان پوشه git status را اجرا کنید و انتظار آن‌قدر طولانی است که ذهنتان جای دیگری برود. این دو مشاهده متناقض نیستند، چون انتقال انبوه توان عبوری را می‌سنجد، در حالی که Git می‌سنجد در هر ثانیه چند پرسش کوچک از فایل‌سیستم می‌تواند بپرسد، و یک درخت راه‌دور سوارشده هر پرسش را به یک رفت‌وبرگشت تبدیل می‌کند. تنظیم VPN کارِ بدشکل را درست نمی‌کند.

چرا status معیار اشتباهی است

Git باید دربارهٔ فایل‌های زیادی بداند: کدام تغییر کرده، کدام ردیابی نشده، و آیا داده‌های نهان‌شدهٔ ایندکس هنوز با آنچه روی دیسک است می‌خواند. روی SSHFS هر یک از این مشاهدات می‌تواند یک عملیات شبکه باشد. واحد کار اینجا شمار فایل‌هاست، نه مگابایت‌ها.

به همین دلیل نخستین status پس از کلون کند است، و به همین دلیل بعدی‌ها می‌توانند در درختی پر از خروجی ساخت حتی کندتر باشند. پیمایش فایل‌های ردیابی‌نشده از پوشه‌هایی می‌گذرد که شاید برایتان مهم نباشند، و هر گام درخواست دیگری از مسیر است. روی مسیری با 40 ms، درختی با چند هزار ورودی به چند هزار رفت‌وبرگشت تبدیل می‌شود. برای تأیید این حساب به عکس‌برداری بسته نیاز نیست.

معیار دانلود به شما می‌گوید مسیر خوب است؛ چیزی نمی‌گوید دربارهٔ اینکه هزار خواندن کوچک امروز بعدازظهر تمام می‌شود یا نه.

درخت کار را جابه‌جا کنید، نه پیچ‌های تنظیم

کلون محلی درخت کار، ایندکس و عملیات Git را روی یک ماشین می‌گذارد. pull به یک گام شبکهٔ دیدنی تبدیل می‌شود، نه هر بررسی فایل.

این هرگاه توسعه‌دهنده بتواند منبع لازم را محلی نگه دارد مناسب است، که بیشتر وقت‌ها چنین است. مرز commit و استقرار را هم تیزتر می‌کند، چون ویرایش یک فایل محلی دیگر تصادفی سرویس راه‌دور در حال اجرا را تغییر نمی‌دهد؛ تغییر باید مثل هر چیز دیگری push و مستقر شود. بهایش این است که کد در دو جا وجود دارد، پس تصمیم بگیرید کدام نسخه معتبر است و اصلاح فوری روی سرور چگونه به مخزن برمی‌گردد. آن گفت‌وگو از فرمان status که هیچ‌کس نمی‌خواهد اجرا کند ارزان‌تر است.

اگر فضای کار باید راه‌دور بماند، Git را همان‌جا اجرا کنید

گاهی فضای کار جابه‌جا نمی‌شود: ساخت به آن محیط نیاز دارد، داده‌ها بسیار بزرگ‌اند، یا سیاست منبع را روی میزبان نگه می‌دارد. آن‌گاه Git و ابزارهای توسعهٔ مربوط را کنار فایل‌ها اجرا کنید، از طریق پوستهٔ راه‌دور تأییدشده یا محیط توسعهٔ راه‌دور. ویرایشگر می‌تواند روی لپ‌تاپ بماند در حالی که بخش پشتی‌اش کنار درخت کار کار می‌کند.

عملیات گران آن‌گاه به‌صورت محلی روی میزبان راه‌دور رخ می‌دهد، و شبکه ترافیک ویرایشگر را حمل می‌کند نه هزاران فراخوانی stat. همان اصلاح کلون محلی است، بیان‌شده به‌عنوان انتخاب استقرار نه مهاجرت.

همگام‌سازی یک گردش کار با مالک است، نه یک نهانگاه

فضای کار همگام‌شده می‌تواند خواندن‌های تکراری راه‌دور را کم کند، اما نهانگاه شفاف نیست. برای هر تغییر مالکی لازم دارد، برای تعارض‌ها قاعده‌ای، و توافقی دربارهٔ فایل‌های تولیدشده که هر دو طرف خود را مالکشان می‌دانند. بدون این قواعد، ترتیب کار اختلاف می‌سازد نه آسودگی.

همگام‌ساز دوسویه بدون آن‌ها مشکلی متفاوت از آنچه حل کرد می‌سازد، معمولاً یک ادغام که هیچ‌کس نمی‌تواند به آن نسبت دهد. از اجرای دو فرایند Git روی یک درخت کار مشترک بپرهیزید مگر اینکه بدانید چگونه هماهنگ می‌شوند.

سپس تنظیم کنید، و SSH را معقول نگه دارید

وقتی ترتیب درست شد، دو تنظیم تغییر می‌دهد که Git دربارهٔ چند فایل بپرسد: status.showUntrackedFiles و نهانگاه ردیابی‌نشده‌ها پشت core.untrackedCache. هیچ‌کدام هزینهٔ هر پرسش روی 40 ms را تغییر نمی‌دهد؛ فقط شمار پرسش‌ها را تغییر می‌دهند. پیچ را تنها وقتی بچرخانید که رفت‌وبرگشت‌ها محلی شده‌اند.

زمان فرمانی را که آزارتان می‌دهد بگیرید، نه اینکه از معیاری که یک فایل بزرگ را کپی می‌کند استدلال کنید، و رمزنگاری SSH پشتیبانی‌شده را به حال خود بگذارید. رمز قدیمی رفت‌وبرگشت را کوتاه نمی‌کند؛ مشکل دومی اضافه می‌کند که از اولی بیشتر می‌ماند. مرجع git status ارزش یک بار خواندن را دارد، چون فرمان بسیار بیشتر از آنچه نامش می‌گوید کار می‌کند.