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 مرجع د یو ځل لوستلو ارزښت لري، ځکه کمانډ له خپل نوم څخه ډېر کار کوي.