Development के लिए WSL या VPS: क्या बेहतर है?

क्या आपको डेवलपमेंट के लिए WSL का उपयोग करना चाहिए या VPS का?

डेवलपमेंट के लिए WSL बनाम VPS का चुनाव एक मुख्य विशेषता पर निर्भर करता है: उपलब्धता। WSL (Windows Subsystem for Linux) एक virtual machine के भीतर Ubuntu चलाता है, जो आपके Windows session के साथ ही शुरू और बंद होता है। एक VPS (virtual private server) उसी Ubuntu को एक public IP address पर चलाता है, जो आपके laptop के बंद होने पर भी चालू रहता है। अधिकांश डेवलपर्स अंततः दोनों का उपयोग करते हैं, जहाँ server वह मशीन होती है जो हमेशा reachable रहती है।

Operating system कोई महत्वपूर्ण अंतर नहीं है, क्योंकि दोनों ही Ubuntu हैं। जो अलग है वह है uptime, internet से reachability, systemd क्या सुनिश्चित कर सकता है, files की गति, network का व्यवहार और backups किसके पास हैं। नीचे दिया गया प्रत्येक खंड एक ऐसा अंतर है जिसे आप अपनी मशीन पर घटित होते देख सकते हैं।

लैपटॉप बंद करने पर WSL क्यों रुक जाता है?

WSL 2 एक हल्के virtual machine में वास्तविक Linux kernel चलाता है, जिसे Windows आवश्यकता पड़ने पर शुरू करता है। वह virtual machine केवल तब तक मौजूद रहता है जब तक कोई distribution चल रहा हो, और distribution केवल तब तक चलता है जब तक कोई चीज़ उसका उपयोग कर रही हो। PowerShell से स्थिति की जाँच करें:

wsl --version
wsl --list --running

हर WSL terminal को बंद करें, एक मिनट प्रतीक्षा करें, और फिर wsl --list --running को दोबारा चलाएँ। जब यह रिपोर्ट करे कि कोई भी distribution नहीं चल रहा है, तो आपके द्वारा शुरू किया गया shell समाप्त हो चुका है और उसके साथ वह सब कुछ भी जो उसमें चल रहा था। wsl --shutdown तुरंत वही काम करता है, जो यह परीक्षण करने का एक उपयोगी तरीका है कि restart के बाद आपका setup कैसा व्यवहार करता है।

Sleep और hibernate मोड भी virtual machine को रोक देते हैं। 03:00 बजे database dump करने के लिए सेट किया गया timer ढक्कन बंद होने पर काम नहीं करता है, क्योंकि उसे चलाने वाला kernel निष्पादित नहीं हो रहा होता है। कोई भी चीज़ error log नहीं करती है, इसलिए ऐसा लगता है जैसे job कभी schedule ही नहीं की गई थी। यही एकमात्र व्यवहार लोगों को दूसरे machine की ओर ले जाता है: build queue, chat bot, nightly backup या webhook receiver, इन सभी के लिए एक ऐसे computer की आवश्यकता होती है जो चालू रहे।

क्या WSL में systemd काम करता है?

हाँ। इसका सपोर्ट WSL 0.67.6 में आया था, और पुराने इंस्टॉलेशन में यह डिफ़ॉल्ट रूप से बंद रहता है। इसके बिना, systemctl status ssh यह प्रिंट करता है:

System has not been booted with systemd as init system (PID 1). Can't operate.

सबसे पहले कॉन्फ़िगरेशन फ़ाइल पढ़ें, क्योंकि हो सकता है कि आपके पास पहले से ही एक फ़ाइल हो। यदि इसमें [boot] सेक्शन नहीं है, तो एक जोड़ें; यदि यह पहले से मौजूद है, तो उस सेक्शन के अंदर वह एक लाइन जोड़ दें।

cat /etc/wsl.conf
sudo tee -a /etc/wsl.conf >/dev/null <<'EOF'
[boot]
systemd=true
EOF

PowerShell में wsl --shutdown चलाएँ, एक नया Ubuntu शेल खोलें, और फिर systemctl list-units --type=service --state=running के साथ जाँच करें। यूनिट्स की एक सूची का मतलब है कि systemd PID 1 है, और उस बिंदु से journalctl -b काम करता है।

समस्या यह है कि enable प्रत्येक मशीन पर क्या वादा करता है। एक VPS पर, sudo systemctl enable --now caddy का मतलब है कि सर्विस बूट पर शुरू होती है, इसलिए यह रीबूट या कर्नल अपग्रेड के बाद भी चालू रहती है, भले ही कोई लॉग इन न हो। WSL में इसका मतलब है कि सर्विस तब शुरू होती है जब डिस्ट्रिब्यूशन शुरू होता है, और डिस्ट्रिब्यूशन तब शुरू होता है जब आप टर्मिनल खोलते हैं। इसलिए सर्विस केवल तभी चालू रहती है जब आप काम कर रहे होते हैं, जो कि सर्विस के अस्तित्व के मूल उद्देश्य के विपरीत है। कंटेनर्स में भी यही कमी होती है, इसीलिए Docker Compose सर्विसेज को बूट पर शुरू करना उस बूट पर निर्भर करता है जिसे WSL केवल तभी करता है जब आप ऐसा करने के लिए कहते हैं।

क्या कोई webhook WSL में चल रहे सर्वर तक पहुँच सकता है?

बिना किसी अतिरिक्त सहायता के ऐसा संभव नहीं है, और इसका कारण नेटवर्क लेआउट है। अपने डिफ़ॉल्ट मोड में WSL 2 वर्चुअल मशीन को NAT (नेटवर्क एड्रेस ट्रांसलेशन) के पीछे अपने स्वयं के वर्चुअल एडेप्टर पर रखता है। इस पते को देखें:

ip -4 addr show eth0
ip route show default

यह पता निजी (private) है, और हर बार वर्चुअल मशीन के स्टार्ट होने पर यह फिर से दिया जाता है, इसलिए यह बदलता रहता है। Windows स्वयं अभी भी localhost:3000 तक पहुँच सकता है, क्योंकि WSL localhost कनेक्शन को डिस्ट्रीब्यूशन में फॉरवर्ड करता है। आपके नेटवर्क पर मौजूद कोई अन्य मशीन ऐसा नहीं कर सकती, जब तक कि आप Administrator PowerShell से एक प्रॉक्सी नियम न जोड़ें:

netsh interface portproxy add v4tov4 listenport=3000 listenaddress=0.0.0.0 connectport=3000 connectaddress=172.24.108.3

वह नियम एक विशिष्ट पते को नाम देता है, इसलिए अगली बार पता बदलने पर वह काम करना बंद कर देता है। Mirrored networking बेहतर विकल्प है: इसमें डिस्ट्रीब्यूशन को वही इंटरफेस और पते मिलते हैं जो Windows के पास हैं। अगस्त 2026 तक इसके लिए Windows 11 22H2 या उससे नया वर्ज़न आवश्यक है। इसे %UserProfile%\.wslconfig में रखें और wsl --shutdown चलाएँ:

[wsl2]
networkingMode=mirrored

Mirrored मोड स्थानीय नेटवर्क की समस्या को ठीक करता है। यह आपको सार्वजनिक (public) पता नहीं देता है। आपका राउटर फिर से NAT चलाता है, अधिकांश घरेलू कनेक्शनों में कोई इनबाउंड पोर्ट नहीं होता जिसे आप नियंत्रित कर सकें, और कई ISP उसके ऊपर NAT की एक और परत जोड़ देते हैं। इसलिए GitHub आपके लैपटॉप पर कोई इवेंट POST नहीं कर सकता है, और कोई सहकर्मी आपके डेमो लिंक को नहीं खोल सकता है। एक टनल सर्विस इसका समाधान करती है, लेकिन टनल क्लाइंट लैपटॉप पर चलता है, जिसका अर्थ है कि लैपटॉप को ही चालू रहना होगा।

एक VPS इस समस्या के दूसरे छोर से शुरू होता है। इसके पास एक सार्वजनिक IPv4 पता और आमतौर पर एक सार्वजनिक IPv6 पता होता है, जिसमें केवल वही पोर्ट खुले होते हैं जिन्हें आप खोलते हैं। उस पर एक A रिकॉर्ड पॉइंट करें, 80 और 443 पोर्ट की अनुमति दें, और यह कहीं से भी जवाब देगा। सार्वजनिक सर्टिफिकेट के लिए भी यही शर्त है, क्योंकि HTTP-01 चैलेंज Let's Encrypt को सार्वजनिक नाम पर पोर्ट 80 के माध्यम से एक फ़ाइल लाने के लिए कहता है। Certbot और nginx के साथ Let's Encrypt सर्टिफिकेट प्राप्त करना सर्वर पर पाँच मिनट का काम है और WSL में असंभव है। स्थानीय काम के लिए आप अभी भी अपने CA को Ubuntu ट्रस्ट स्टोर में जोड़कर WSL के अंदर ब्राउज़र-ट्रस्टेड HTTPS प्राप्त कर सकते हैं।

/mnt/c पर git धीमा क्यों है?

इसका कारण यह है कि फाइलें Linux filesystem पर नहीं हैं। WSL आपको दो अलग-अलग स्टोरेज क्षेत्र देता है जिनकी लागत बहुत भिन्न है। आपकी home directory एक virtual disk के अंदर ext4 filesystem पर स्थित है, और यह एक सामान्य Linux disk की तरह व्यवहार करती है। /mnt/c Windows ड्राइव है, जिसे Windows साइड पर एक घटक द्वारा 9P protocol (Plan 9 filesystem protocol) के माध्यम से सर्व किया जाता है, इसलिए हर open और हर stat कॉल को उस सीमा को पार करना पड़ता है।

एक फाइल के लिए यह ठीक है। किसी बड़े repository पर git status चलाने से हजारों stat कॉल होते हैं, और प्रत्येक कॉल को यह सीमा पार करने की लागत चुकानी पड़ती है। किसी के भी द्वारा बताए गए आंकड़ों पर भरोसा करने के बजाय इसे स्वयं मापें, जिसमें यह पेज भी शामिल है:

cd /mnt/c/Users/you/code/myrepo && time git status
cp -r /mnt/c/Users/you/code/myrepo ~/myrepo
cd ~/myrepo && time git status

प्रत्येक को दो बार चलाएँ और दूसरी बार के परिणामों की तुलना करें, ताकि दोनों बार cache warm रहे। Windows का real-time antivirus scanning /mnt/c साइड पर अतिरिक्त लागत जोड़ता है, यही कारण है कि एक ही repository कंपनी के लैपटॉप पर व्यक्तिगत लैपटॉप की तुलना में धीमी महसूस हो सकती है।

WSL के अंदर इसका समाधान यह है कि working copy को ~ के अंतर्गत रखें और इसे अपने editor के WSL remote mode के साथ खोलें, जो editor server को सीमा के पार पहुँचने के बजाय distribution के अंदर चलाता है। Explorer अभी भी उन फाइलों को \\wsl.localhost\Ubuntu\home\you पर ब्राउज़ कर सकता है। VPS में यह समस्या नहीं होती है, क्योंकि वहाँ एक ही filesystem होता है और वह Linux होता है। वहाँ आपको एडिटिंग के दौरान network latency का सामना करना पड़ता है, इसलिए लोग terminal multiplexer या remote editor session में काम करते हैं। छोटे सर्वर पर shared CPU एक वास्तविक चेतावनी है, और noisy neighbour से steal time top में st कॉलम के रूप में दिखाई देता है।

जहाँ WSL पूरी तरह से बेहतर है

• यह मुफ्त है और पहले से ही मशीन पर मौजूद है। इसे चालू करें, Ubuntu इंस्टॉल करें, और आप एक मिनट में काम शुरू कर सकते हैं। इसमें कोई खर्च नहीं है और सुरक्षित रखने के लिए कोई public surface नहीं है।
• यह उस तरह से disposable है जैसे कि सर्वर नहीं होते। wsl --export Ubuntu D:\wsl-backups\ubuntu.tar पूरे distribution को एक फाइल में लिख देता है, और wsl --import उसे restore या दूसरे नाम से clone कर देता है। यहाँ Ubuntu के नए release को आज़माना केवल एक clone और rollback का काम है, जबकि VPS को 24.04 से 26.04 पर अपग्रेड करना एक तरफा प्रक्रिया है जिसे आपको उस पर चल रही सेवाओं के अनुसार schedule करना पड़ता है।
• GPU का काम सीधा होता है। वर्तमान Windows GPU driver के साथ, कार्ड distribution के अंदर उपलब्ध रहता है, इसलिए CUDA और ROCm workloads आपके पास मौजूद हार्डवेयर पर चलते हैं। उसी श्रेणी के GPU को प्रति घंटे किराए पर लेने में वास्तविक पैसे खर्च होते हैं।
• एडिटिंग लूप छोटा होता है। आपकी फाइलें और ब्राउज़र दोनों local होते हैं, इसलिए localhost:5173 पर चल रहा dev server उसी ब्राउज़र में खुलता है जिसमें आप पहले से ही signed-in हैं।

ये वास्तविक लाभ हैं, और यही कारण है कि सामान्य उत्तर एक मशीन के बजाय दोनों मशीनों का उपयोग करना है।

बैकअप का स्वामित्व किसके पास है?

दोनों मशीनों पर बैकअप का स्वामित्व आपके पास है, और WSL के मामले में यह बात लोगों को हैरान करती है। यह डिस्ट्रीब्यूशन आपके Windows यूजर प्रोफाइल के अंदर एक वर्चुअल डिस्क फाइल (ext4.vhdx) है। कोई भी प्रोवाइडर आपके लिए इसका स्नैपशॉट नहीं लेता है। wsl --unregister Ubuntu इसे बिना किसी अनडू (undo) विकल्प के डिलीट कर देता है, और Windows को रीइंस्टॉल करने पर यह बाकी सब चीजों के साथ मिट जाता है। इसे एक ऐसे शेड्यूल पर एक्सपोर्ट करें जिसका आप वास्तव में पालन कर सकें:

wsl --export Ubuntu D:\wsl-backups\ubuntu-2026-08-18.tar

VPS पर, प्रोवाइडर का स्नैपशॉट आपको डेड होस्ट (dead host) से बचाता है। यह आपको गलत डायरेक्टरी में rm -rf चलाने से नहीं बचाता है, और यदि स्नैपशॉट उसी अकाउंट में रखा गया है जिसमें सर्वर है, तो एक लॉगिन चोरी होने पर वह भी सर्वर के साथ ही चला जाएगा। फाइल-लेवल बैकअप को सर्वर से बाहर भेजें (push), और जरूरत पड़ने से पहले एक बार रिस्टोर करके देखें। दोनों ही स्थितियों में जिम्मेदारी आपकी है। व्यावहारिक अंतर यह है कि एक सर्वर किसी से लैपटॉप खुला रखने के लिए कहे बिना, रात के 03:00 बजे अपना बैकअप खुद भेज सकता है।

ब्रिज: WSL से VPS तक SSH

जब तक कनेक्शन ठीक से सेटअप न हो जाए, तब तक दूसरी मशीन का उपयोग करना बोझिल लग सकता है। WSL के अंदर इसे एक बार करें।

Windows साइड के बजाय Linux डिस्ट्रिब्यूशन में ही key जनरेट करें, ताकि private key ext4 फाइलसिस्टम पर रहे और उसमें वे Unix अनुमतियाँ (permissions) हों जिन्हें ssh स्वीकार करता है:

ssh-keygen -t ed25519 -C "dev@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub root@203.0.113.10

Ed25519 keys छोटी और तेज़ होती हैं, और ssh-copy-id सर्वर पर ~/.ssh/authorized_keys में सही मोड्स के साथ public key को जोड़ देता है। SSH key प्रबंधन की मूल बातें में बाद में इन्हें रोटेट और रद्द करने की जानकारी दी गई है।

~/.ssh/config में सर्वर को एक नाम दें:

Host dev
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519
  IdentitiesOnly yes
  ForwardAgent yes
  ServerAliveInterval 30

अब ssh dev कनेक्ट हो जाता है। IdentitiesOnly yes क्लाइंट को हर उपलब्ध key ऑफर करने से रोकता है, जो कि तब Too many authentication failures का कारण बनता है जब एजेंट में कई keys लोड हों। ServerAliveInterval 30 होम कनेक्शन पर सेशन को बिना किसी संदेश के समाप्त होने से बचाता है।

ForwardAgent yes वह लाइन है जो वर्कफ़्लो को आसान बनाती है। लैपटॉप पर एजेंट में आपकी key लोड होने के साथ, git clone git@github.com:you/app.git सर्वर पर बिना किसी private key के वहां पहुंचे काम करता है। VPS से ssh -T git@github.com के साथ इसका परीक्षण करें, जिसे Hi you! You've successfully authenticated का उत्तर देना चाहिए। एजेंट को केवल उन सर्वरों पर फॉरवर्ड करें जिन पर आप भरोसा करते हैं, क्योंकि उस मशीन पर root उपयोगकर्ता आपके कनेक्ट रहने के दौरान आपके एजेंट सॉकेट का उपयोग कर सकता है। ऐसे सर्वर पर जिसे आप अन्य लोगों के साथ साझा करते हैं, प्रति रिपॉजिटरी deploy key एक सुरक्षित विकल्प है।

WSL शेल के बीच एजेंट को जीवित नहीं रखता है, इसलिए हर नया टर्मिनल फिर से key मांगता है। keychain इसे हल करता है:

sudo apt update && sudo apt install -y keychain
echo 'eval "$(keychain --eval --quiet id_ed25519)"' >> ~/.bashrc

एक नया शेल खोलें और ssh-add -l चलाएं। इसे key का फिंगरप्रिंट प्रिंट करना चाहिए। इसके बजाय Error connecting to agent का मतलब है कि लाइन पढ़ी नहीं जा रही है, इसलिए जांचें कि आपका शेल वास्तव में ~/.bashrc को सोर्स कर रहा है या नहीं।

सर्वर पर अपना काम टर्मिनल मल्टीप्लेक्सर के अंदर चलाएं, ताकि कनेक्शन टूटने पर वह बंद न हो:

tmux new -s dev
# Ctrl-b then d to detach
tmux attach -t dev

लैपटॉप बंद करने के बाद भी बिल्ड चलता रहता है, जो दूसरी मशीन का उपयोग करने का मुख्य कारण है। इसी पैटर्न का उपयोग करके लोग tmux में VPS पर Claude Code चलाते हैं और किसी अन्य डिवाइस से सेशन को फिर से शुरू कर लेते हैं।

सर्वर पर कुछ भी डालने से पहले उसे सुरक्षित (harden) करें। नए VPS पर पहले दस मिनट में non-root उपयोगकर्ता, केवल-key SSH, फायरवॉल और स्वचालित सुरक्षा अपडेट की प्रक्रिया बताई गई है, उस क्रम में जिससे आप लॉक न हों।

किस काम के लिए कौन सी मशीन?

जब काम आपकी स्क्रीन पर हो, तब WSL का उपयोग करें। एडिटिंग, टेस्ट सूट चलाना, localhost पर dev सर्वर, नोटबुक, GPU प्रयोग, या ऐसा कुछ भी जिसे आप शुरू करते हैं और फिर देखते हैं, उसके लिए यह उपयुक्त है।

जब काम को सुलभ बनाना हो या उसे आपके सेशन के समाप्त होने के बाद भी चलते रहना हो, तब VPS का उपयोग करें। एक staging URL जिसे क्लाइंट खोल सके, एक webhook endpoint, वास्तविक समय के साथ चलने वाला cron job, एक बॉट, एक छोटा डेटाबेस जिससे कोई अन्य सर्विस बात करती हो, या शुक्रवार दोपहर को शुरू किया गया कोई import, इन सबके लिए VPS का उपयोग करें।

यदि आप अभी भी यह तय कर रहे हैं कि दूसरी मशीन किस लिए है, तो VPS पर लोग वास्तव में क्या चलाते हैं एक स्पेसिफिकेशन तुलना की तुलना में अधिक उपयोगी सूची है, और VPS क्या है इसके पीछे के वर्चुअलाइजेशन को समझाता है। यदि आपकी टूलिंग केवल Windows पर चलती है, तो यह एक अलग निर्णय है, और Linux बनाम Windows Server इसके लिए सही पेज है।

एक आदत दो मशीनों को दो आधी-अधूरी कॉन्फ़िगर की गई मशीनों बनने से रोकती है: कोड git में रहता है, और दोनों मशीनें रिपॉजिटरी की क्लाइंट होती हैं। कोई भी महत्वपूर्ण चीज़ केवल एक मशीन में मौजूद नहीं होनी चाहिए।

FAQ

क्या मैं WSL से एक असली domain के साथ वेबसाइट होस्ट कर सकता हूँ?

विश्वसनीय रूप से नहीं। WSL 2 आपकी मशीन के अंदर NAT के पीछे होता है, आपका राउटर फिर से NAT चलाता है, और अधिकांश घरेलू कनेक्शन आपको फॉरवर्ड करने के लिए कोई इनबाउंड पोर्ट नहीं देते हैं। एक टनल सर्विस लोकल पोर्ट को एक्सपोज़ कर सकती है, लेकिन टनल क्लाइंट लैपटॉप पर चलता है, इसलिए लैपटॉप के स्लीप मोड में जाते ही साइट डाउन हो जाती है। सर्टिफिकेट इसे और भी कठिन बना देते हैं, क्योंकि HTTP-01 चैलेंज के लिए Let's Encrypt को पब्लिक नाम पर पोर्ट 80 के माध्यम से एक फाइल फेच करने की आवश्यकता होती है। पब्लिक IP एड्रेस और A रिकॉर्ड वाला एक VPS बिना किसी वर्कअराउंड के दोनों शर्तों को पूरा करता है।

क्या systemctl enable WSL में काम करता है?

यह तब काम करता है जब systemd चालू हो, जिसका अर्थ है /etc/wsl.conf में [boot] के अंतर्गत systemd=true और उसके बाद wsl --shutdown। इसके बिना, systemctl का जवाब System has not been booted with systemd as init system (PID 1). Can't operate. होता है। systemd चलने के बावजूद, enable सर्विस को तब शुरू करता है जब डिस्ट्रिब्यूशन शुरू होता है, और डिस्ट्रिब्यूशन तब शुरू होता है जब आप शेल खोलते हैं। सर्वर पर उसी कमांड का मतलब है कि बिना किसी के लॉग इन किए रीबूट के बाद सर्विस वापस आ जाती है।

मेरा WSL IP एड्रेस बार-बार क्यों बदलता है?

डिफ़ॉल्ट NAT मोड में, वर्चुअल मशीन हर बार शुरू होने पर WSL वर्चुअल एडेप्टर से एक नया प्राइवेट एड्रेस प्राप्त करती है। कोई भी netsh interface portproxy नियम या हार्ड-कोडेड एड्रेस wsl --shutdown के बाद काम करना बंद कर देता है। ip -4 addr show eth0 के साथ वर्तमान एड्रेस की जाँच करें। Windows 11 पर Mirrored networking मोड डिस्ट्रिब्यूशन को Windows वाले ही इंटरफेस देकर अलग एड्रेस की समस्या को खत्म कर देता है: %UserProfile%\.wslconfig में [wsl2] के अंतर्गत networkingMode=mirrored सेट करें।

क्या /mnt/c वास्तव में धीमा है, या यह सिर्फ एक मिथक है?

यह धीमा है, और एक मिनट का परीक्षण आपकी अपनी मशीन पर इसे साबित कर देता है। ~ के अंतर्गत फाइलें ext4 वर्चुअल डिस्क पर रहती हैं। /mnt/c के अंतर्गत फाइलें Windows-साइड कंपोनेंट द्वारा 9P प्रोटोकॉल पर सर्व की जाती हैं, इसलिए प्रत्येक stat कॉल बाउंड्री पार करती है और एक बड़े ट्री पर git status करने से हजारों ऐसी कॉल होती हैं। रिपॉजिटरी को ~ पर कॉपी करें, प्रत्येक स्थान पर time git status को दो बार चलाएं, और वार्म रन की तुलना करें। वर्किंग कॉपी को ~ के अंतर्गत रखें और अपने एडिटर के WSL रिमोट मोड का उपयोग करें।

क्या VPS मिलने के बाद भी मुझे WSL की आवश्यकता है?

अधिकांश लोग दोनों रखते हैं। WSL मुफ़्त है और यह तुरंत शुरू हो जाता है, इसलिए यह वह जगह बनी रहती है जहाँ आप एडिट और टेस्ट करते हैं, और GPU का काम भी वहीं होता है। सर्वर वह मशीन है जो चालू रहती है: यह पब्लिक नाम रखती है और उन जॉब्स को चलाती है जिन्हें लैपटॉप बंद होने के बाद भी चलते रहना चाहिए। कोड को git में रखें और दोनों को रिपॉजिटरी के क्लाइंट के रूप में उपयोग करें, इससे उनके बीच काम को स्थानांतरित करने में कोई लागत नहीं आती है।