Git बनाम GitHub बनाम अपना Git सर्वर: मुख्य अंतर क्या हैं?

Git बनाम GitHub बनाम Git सर्वर: संक्षिप्त उत्तर

Git एक कंप्यूटर पर इंस्टॉल किया गया प्रोग्राम है। यह बिना किसी अकाउंट और बिना नेटवर्क के चलता है। GitHub एक होस्ट की गई सेवा है जो Git रिपॉजिटरी की एक कॉपी रखती है और उसके चारों ओर एक वेबसाइट प्रदान करती है। Git सर्वर कोई भी ऐसी मशीन है जिसे डेवलपर नियंत्रित करता है और जो एक और कॉपी रखती है, जिसे SSH (secure shell) के माध्यम से एक्सेस किया जाता है। इन तीनों में "git" शब्द का प्रयोग होता है, यही कारण है कि प्रथम वर्ष का छात्र इन्हें एक ही लैब सत्र में देखता है और यह सोचकर निकलता है कि ये तीनों एक ही चीज हैं।

यह अंतर कुछ समय के लिए केवल अकादमिक बना रहता है। यह चार विशिष्ट दिनों पर वास्तविक हो जाता है: जिस दिन क्लाइंट यह मांग करता है कि कोड उनके द्वारा नियंत्रित इंफ्रास्ट्रक्चर पर रहे, जिस दिन continuous integration (CI) का कोटा समाप्त हो जाता है, जिस दिन GitHub तक नहीं पहुँचा जा सकता और फिर भी commit करना आवश्यक होता है, और जिस दिन एक अकाउंट में चार साल के कोर्सवर्क की एकमात्र कॉपी होती है। यह गाइड इन तीनों के बीच अंतर स्पष्ट करती है, और फिर पासवर्ड के बजाय SSH keys का उपयोग करके, एक GitHub अकाउंट से एक virtual private server (VPS) पर दूसरे रिमोट तक जाने का मार्ग बताती है।

जब नेटवर्क बंद हो तो लैपटॉप पर Git क्या करता है

git init प्रोजेक्ट फोल्डर के शीर्ष पर .git नामक एक एकल हिडन डायरेक्टरी बनाता है। प्रत्येक कमिट, ब्रांच, टैग और पूरा इतिहास उसी डिस्क पर, उस डायरेक्टरी के अंदर रहता है। कुछ भी कहीं नहीं भेजा जाता है।

mkdir demo && cd demo
git init
git config user.name "Example Student"
git config user.email "student@example.com"
echo "hello" > README.md
git add README.md
git commit -m "First commit"
git log --oneline

git log --oneline एक लाइन प्रिंट करता है जिसमें एक छोटा कमिट हैश और मैसेज होता है। यह वाईफाई बंद होने पर, बिना केबल वाली लैब में, या ट्रेन में भी काम करता है। उस ब्लॉक का कोई भी चरण नेटवर्क सॉकेट नहीं खोलता है, इसलिए नेटवर्क के कारण कोई भी चरण विफल नहीं हो सकता है।

"Remote" उस URL के लिए एक सहेजा गया नाम है जहाँ उसी रिपॉजिटरी की एक और कॉपी मौजूद है। एक नई रिपॉजिटरी में कोई रिमोट नहीं होता है, और git remote -v कुछ भी प्रिंट नहीं करता है। GitHub तभी तस्वीर में आता है जब कोई रिमोट जोड़ता है और git push चलाता है। यह एक तथ्य अधिकांश भ्रम को दूर कर देता है। Git, GitHub के बिना पूर्ण है, और GitHub उन कई स्थानों में से एक है जहाँ Git रिपॉजिटरी को कॉपी किया जा सकता है।

Distributed का अर्थ है कि प्रत्येक क्लोन एक पूर्ण रिपॉजिटरी है। जिस लैपटॉप ने पिछले सप्ताह एक प्रोजेक्ट क्लोन किया था, उसमें अभी भी उस प्रोजेक्ट का पूरा इतिहास मौजूद है, जिसमें क्लोन होने से पहले किए गए सभी कमिट शामिल हैं। यह पुराने वर्शन कंट्रोल सिस्टम की तरह किसी केंद्रीय कॉपी का केवल एक छोटा सा हिस्सा (thin checkout) नहीं है।

GitHub, Git के ऊपर क्या जोड़ता है

Pull requests, issue tracking, review threads, Actions workflows, releases, forks, organisation permissions और dependency alerts। इनमें से कोई भी Git के features नहीं हैं। Git में pull request जैसी कोई अवधारणा नहीं है। इसके सबसे करीब जो सुविधा यह ships करता है वह है git request-pull, जो एक plain text summary print करता है जिसे email में paste करने के लिए बनाया गया है। Review interface, merge button और comment threads GitHub का product हैं, जिन्हें Git के अंदर नहीं बल्कि उसके ऊपर बनाया गया है। GitHub एक hosted service के रूप में क्या है इस पहलू को विस्तार से कवर करता है।

Storage का आधा हिस्सा सामान्य Git है। GitHub URL का एक git clone एक ऐसा repository तैयार करता है जिसे commits, branches, merges या history के लिए अब GitHub की आवश्यकता नहीं होती। Clone अपने साथ code के इर्द-गिर्द हुई चर्चा को नहीं ले जाता, क्योंकि वह कभी Git में मौजूद ही नहीं थी।

GitHub student account में क्या शामिल है, अगस्त 2026 तक

GitHub Free में private repositories शामिल हैं, इसलिए coursework को स्टोर करने के लिए उसे public करने की आवश्यकता नहीं है। Public repositories पर GitHub-hosted CI runners बिना किसी शुल्क के चलते हैं, और private repositories के लिए मासिक निर्धारित allowance का उपयोग होता है।

Actions minutes और package storage के लिए सटीक allowance बदलते रहते हैं, और किसी भी ट्यूटोरियल में छपी संख्या कुछ ही महीनों में गलत हो जाती है। https://github.com/pricing पर GitHub का अपना pricing page ही वह स्थान है जिस पर भरोसा किया जा सकता है, और यह गाइड जानबूझकर उन संख्याओं को दोहराती नहीं है।

https://education.github.com/pack पर उपलब्ध GitHub Student Developer Pack नामांकन सत्यापित होने के बाद और अधिक लाभ जोड़ता है। सत्यापन के लिए ऐसे प्रमाण की आवश्यकता होती है जिसमें छात्र का नाम और वर्तमान शैक्षणिक सत्र का उल्लेख हो। आमतौर पर इसके लिए एक संस्थागत ईमेल पते का उपयोग किया जाता है, और यदि ईमेल डोमेन की पहचान नहीं होती है, तो बैकअप के रूप में एक दस्तावेज़ अपलोड करना होता है। पैक के भीतर मिलने वाले ऑफ़र अन्य कंपनियों द्वारा दिए जाते हैं और यह सूची अक्सर बदलती रहती है, इसलिए पैक पेज ही इसका एकमात्र विश्वसनीय इन्वेंट्री है।

एक चेतावनी किसी भी allowance से अधिक महत्वपूर्ण है। Student account एक एकल खाता होता है। Multi-factor authentication (MFA) डिवाइस खो जाने, खाता निलंबित होने या गलती से organisation ट्रांसफर होने पर सभी private repositories का एक्सेस एक साथ समाप्त हो जाता है। Two-factor authentication चालू होने पर GitHub recovery codes जारी करता है, और उन कोड्स को लैपटॉप के अलावा किसी अन्य सुरक्षित स्थान पर रखना ही एक छोटी देरी और स्थायी रूप से लॉक होने के बीच का अंतर है। एक दूसरा remote repository इस सुरक्षा का दूसरा हिस्सा है।

यह अंतर अकादमिक क्यों नहीं रह जाता

एक क्लाइंट यह चाहता है कि कोड उनके द्वारा नियंत्रित इंफ्रास्ट्रक्चर पर रहे। कुछ अनुबंध और अधिकांश सार्वजनिक क्षेत्र के टेंडर यह निर्दिष्ट करते हैं कि सोर्स कोड और बिल्ड आर्टिफैक्ट्स कहाँ रखे जा सकते हैं। एक होस्टेड अकाउंट उस क्लॉज को पूरा नहीं कर सकता जो किसी सर्वर और देश का नाम लेता है। उस देश में स्थित VPS पर एक बेयर रिपॉजिटरी ऐसा कर सकती है, और डेवलपर उसी तरह काम करना जारी रखता है।

CI का कोटा समाप्त हो जाता है। प्राइवेट रिपॉजिटरी पर वर्कफ़्लो तब तक शुरू होना बंद हो जाते हैं जब तक कि शामिल किए गए मिनट समाप्त हो जाते हैं, या तो अगले बिलिंग पीरियड तक या जब तक भुगतान की सीमा नहीं बढ़ाई जाती। रिपॉजिटरी स्वयं सुरक्षित रहती है। केवल ऑटोमेशन रुकता है। एक समाधान यह है कि GitHub को रिमोट के रूप में बनाए रखा जाए और कंप्यूट को कहीं सस्ता स्थानांतरित कर दिया जाए: VPS पर एक self-hosted GitHub Actions runner उन्हीं वर्कफ़्लो फ़ाइलों को एक ऐसी मशीन पर निष्पादित करता है जिसका बिल मिनट के बजाय महीने के आधार पर आता है।

GitHub तक पहुँच नहीं है। आउटेज के दौरान, या किसी कैंपस नेटवर्क पर जो आउटबाउंड कनेक्शन को ब्लॉक करता है, git commit काम करना जारी रखता है क्योंकि कमिट एक स्थानीय ऑपरेशन है। केवल git push और git fetch विफल होते हैं। काम जारी रहता है और कमिट स्थानीय रूप से कतार में लग जाते हैं जब तक कि नेटवर्क वापस नहीं आ जाता। VPS पर एक दूसरा रिमोट उस कतार को एक ऐसे पुश में बदल देता है जो सफल रहता है।

एक अकाउंट में ही एकमात्र कॉपी होती है। दो रिमोट का मतलब है दो स्वतंत्र कॉपी और दो स्वतंत्र विफलता मोड। दैनिक वर्कफ़्लो में एक अतिरिक्त पुश के अलावा कुछ भी नहीं बदलता है।

VPS पर दूसरा remote कैसे जोड़ें

सबसे छोटा उपयोगी Git सर्वर OpenSSH और git पैकेज का संयोजन है। इसमें कोई वेब इंटरफेस या डेटाबेस नहीं होता। Git SSH कनेक्शन के माध्यम से अपने स्वयं के प्रोटोकॉल का उपयोग करता है, इसलिए जो account पहले से ही SSH के जरिए login कर सकता है, वह repositories को host कर सकता है।

Ubuntu 24.04 चलाने वाले VPS पर, sudo अधिकार वाले user के रूप में:

sudo apt update && sudo apt install -y git
sudo adduser --disabled-password --gecos "" git
sudo install -d -m 700 -o git -g git /home/git/.ssh
sudo install -d -m 755 -o git -g git /home/git/repos

--disabled-password बिना किसी उपयोगी password के account बनाता है, इसलिए अंदर जाने का एकमात्र तरीका key है। अगला चरण developer की public key है। .pub फ़ाइल public हिस्सा है और इसे कहीं भी copy करना सुरक्षित है। बिना .pub वाली फ़ाइल कभी भी laptop से बाहर नहीं जानी चाहिए।

sudo tee -a /home/git/.ssh/authorized_keys < /tmp/id_ed25519.pub > /dev/null
sudo chown git:git /home/git/.ssh/authorized_keys
sudo chmod 600 /home/git/.ssh/authorized_keys

ये modes आवश्यक हैं। sshd डिफ़ॉल्ट रूप से StrictModes के साथ चलता है, इसलिए यदि /home/git या /home/git/.ssh group या others द्वारा writable हैं, तो यह key फ़ाइल को ignore कर देता है। इसके बाद client को बिना किसी स्पष्टीकरण के Permission denied (publickey). दिखाई देता है, जबकि सर्वर log वास्तविक कारण बताता है: Authentication refused: bad ownership or modes for directory /home/git/.ssh।

Repository को bare repository के रूप में बनाएँ:

sudo -u git git init --bare /home/git/repos/project.git

Bare का अर्थ है कि इसमें कोई working tree नहीं है। यह directory केवल वही रखती है जो एक .git फ़ोल्डर सामान्य रूप से रखता है, और कुछ नहीं। यह महत्वपूर्ण है, क्योंकि Git एक सामान्य repository द्वारा checked out branch में push करने से मना कर देता है, और remote: error: refusing to update checked out branch: refs/heads/main प्रिंट करता है। Bare repository में कोई checked out branch नहीं होती, इसलिए हर push स्वीकार कर लिया जाता है।

Laptop पर वापस, मौजूदा project के अंदर:

git remote -v
git remote add vps git@203.0.113.10:repos/project.git
git push vps --all
git push vps --tags
git ls-remote vps

बदलाव से पहले git remote -v चलाने पर GitHub remote दो बार प्रिंट होता है, एक बार (fetch) के रूप में और एक बार (push) के रूप में। बदलाव के बाद यह चार लाइनें प्रिंट करता है। git ls-remote vps सर्वर पर प्रत्येक ref को उसके full hash के साथ प्रिंट करता है, जो इस बात का प्रमाण है कि objects पहुँच गए हैं। खाली output का मतलब है कि कुछ भी push नहीं हुआ।

Path repos/project.git, git user की home directory के सापेक्ष (relative) है, इसलिए यह /home/git/repos/project.git पर resolve होता है। एक absolute path भी काम करता है। ध्यान दें कि git push vps --all सभी branches भेजता है लेकिन tags नहीं, इसीलिए tag push एक अलग command है।

यदि VPS 22 के अलावा किसी अन्य port पर listen कर रहा है, तो संक्षिप्त git@host:path फॉर्म उसे carry नहीं कर सकता। पूर्ण URL फॉर्म ऐसा कर सकता है: ssh://git@203.0.113.10:2222/home/git/repos/project.git। उस port को बदलना एक सामान्य hardening step है, और SELinux और firewalld सिस्टम पर SSH port बदलना उस हिस्से को कवर करता है जिसे Rocky और AlmaLinux पर अक्सर अनदेखा कर दिया जाता है।

SSH keys रिमोट के लिए पासवर्ड की जगह क्यों लेती हैं

SSH (secure shell) वह प्रोटोकॉल है जिसका उपयोग यहाँ दोनों रिमोट करते हैं, और SSH कनेक्शन को कैसे प्रमाणित करता है इसके पीछे की handshake प्रक्रिया को समझाता है। व्यावहारिक सारांश: एक key pair को एक बार generate किया जाता है, public हिस्से को प्रत्येक सर्वर को दिया जाता है, और private हिस्सा बिना कभी transmit हुए पहचान साबित करता है।

ssh-keygen -t ed25519 -C "student@example.com"
cat ~/.ssh/id_ed25519.pub

GitHub पक्ष उसी public key को लेता है, जिसे account settings के SSH keys पेज में paste किया जाता है। परीक्षण के लिए एक command पर्याप्त है:

ssh -T git@github.com

एक कार्यशील key Hi username! You've successfully authenticated, but GitHub does not provide shell access. प्रिंट करती है। यह सफलता है, त्रुटि नहीं। GitHub जानबूझकर उस account पर कोई shell नहीं देता है।

13 अगस्त 2021 से Git operations के लिए HTTPS पर पासवर्ड काम करना बंद कर चुके हैं, और संदेश बिल्कुल यही कहता है: remote: Support for password authentication was removed on August 13, 2021. HTTPS को अब एक personal access token की आवश्यकता होती है, जो एक पासवर्ड है जिसके साथ scope list और expiry date जुड़ी होती है। Keys इस renewal cycle से बचाती हैं। कई मशीनों और कई सर्वरों के साथ key handling अपने आप में एक bookkeeping समस्या बन जाती है, जिसे मशीनों के बीच SSH keys को व्यवस्थित रखना हल करता है।

कई कैंपस और ऑफिस नेटवर्क outbound port 22 को ब्लॉक करते हैं। इसका लक्षण ssh: connect to host github.com port 22: Connection timed out है। GitHub port 443 पर भी SSH का उत्तर देता है, इसलिए ~/.ssh/config में चार लाइनें इसे ठीक कर देती हैं:

Host github.com
  Hostname ssh.github.com
  Port 443
  User git

ssh -T git@github.com फिर 443 पर सफल हो जाता है। जब key सही दिखती है लेकिन कनेक्शन फिर भी अस्वीकार कर दिया जाता है, तो Permission denied (publickey) के पीछे के विशिष्ट कारण उन कारणों को सूचीबद्ध करते हैं जो client side से एक जैसे दिखते हैं।

इंटरनेट के लिए SSH open रखने वाला VPS पहली बार boot होने के कुछ घंटों के भीतर ही login के प्रयास प्राप्त करने लगता है। दो सेटिंग्स सबसे महत्वपूर्ण हैं: /etc/ssh/sshd_config.d/ के अंतर्गत एक फाइल में PasswordAuthentication no, और Ubuntu 24.04 पर SSH के लिए fail2ban कॉन्फ़िगरेशन ताकि बार-बार प्रयास करने वाले hosts को drop किया जा सके।

GitHub और VPS पर एक ही कमांड में पुश कैसे करें

दो अलग-अलग नामों वाले दो रिमोट का मतलब है दो बार पुश करना। Git एक ही रिमोट नाम के तहत कई URLs पर एक साथ पुश भेज सकता है:

git remote set-url --add --push origin git@github.com:student/project.git
git remote set-url --add --push origin git@203.0.113.10:repos/project.git
git remote -v

git remote -v अब origin के लिए दो (push) लाइनें दिखाता है। git push origin main सूचीबद्ध क्रम में दोनों पर लिखता है। GitHub URL को स्पष्ट रूप से पहले जोड़ना आवश्यक है, क्योंकि कोई भी नया पुश URL जोड़ने पर वह डिफ़ॉल्ट URL को बदल देता है जो fetch URL से आया था। Fetching अभी भी केवल fetch URL का उपयोग करती है, इसलिए यह एक 'write fan-out' है, न कि 'two-way sync'।

यदि दूसरी कॉपी पूरी तरह से बैकअप के रूप में मौजूद है, तो मिरर एक बेहतर विकल्प है:

git clone --mirror git@github.com:student/project.git project.git
cd project.git
git remote set-url --push origin git@203.0.113.10:repos/project.git
git fetch -p origin
git push --mirror

यह हर ref को कॉपी करता है, जिसमें वे branches और tags भी शामिल हैं जिन्हें किसी ने चेक आउट नहीं किया है। --mirror डेस्टिनेशन पर उन refs को भी हटा देता है जो अब सोर्स पर मौजूद नहीं हैं। यह बैकअप के लिए सही है, लेकिन यदि गलती से दिशा बदल दी जाए तो यह विनाशकारी हो सकता है।

क्या खराब होता है और हर बार क्या संदेश प्रिंट होता है

गलत डायरेक्टरी। fatal: not a git repository (or any of the parent directories): .git का अर्थ है कि कमांड किसी रिपॉजिटरी के बाहर चलाई गई थी। कुछ भी खराब नहीं हुआ है और इसमें नेटवर्क शामिल नहीं है।

नाम रिज़ॉल्यूशन विफल रहा। fatal: unable to access 'https://github.com/student/project.git/': Could not resolve host: github.com का अर्थ है DNS (डोमेन नेम सिस्टम)। कमिट अभी भी काम करते हैं; केवल ट्रांसफर विफल हुआ है।

की (key) स्वीकार नहीं की गई। git@203.0.113.10: Permission denied (publickey). का अर्थ है कि सर्वर ने क्लाइंट द्वारा दी गई हर की (key) को अस्वीकार कर दिया। ssh -v git@203.0.113.10 उन की (key) फाइलों की सूची देता है जिन्हें आजमाया गया था। सर्वर पर, sudo journalctl -u ssh -n 50 वास्तविक कारण बताता है, जो अक्सर पहले वर्णित डायरेक्टरी मोड होते हैं।

लॉगिन सफल रहा लेकिन पाथ (path) नहीं। fatal: 'repos/project.git' does not appear to be a git repository, जिसके बाद fatal: Could not read from remote repository. आता है, का अर्थ है कि या तो git init --bare कभी चला ही नहीं या पाथ (path) git यूजर की होम डायरेक्टरी के सापेक्ष गलत है।

रिमोट आगे है। ! [rejected] main -> main (fetch first) का अर्थ है कि सर्वर पर ऐसे कमिट हैं जो लोकल क्लोन में नहीं हैं। पुश करने से पहले git fetch, और फिर मर्ज या रीबेस करना आवश्यक है।

टारगेट बेयर (bare) नहीं है। remote: error: refusing to update checked out branch: refs/heads/main का अर्थ है कि सर्वर रिपॉजिटरी को git init --bare के बजाय git init के साथ बनाया गया था।

सेल्फ-होस्टेड Git सर्वर क्या नहीं देता है

SSH पर एक bare repository केवल स्टोरेज और key-आधारित एक्सेस कंट्रोल प्रदान करती है। यह कोई issue tracker, pull request इंटरफ़ेस, कोड का वेब व्यू या CI प्रदान नहीं करती है। ये सुविधाएँ इसके ऊपर इंस्टॉल किए गए सॉफ़्टवेयर से आती हैं। Gitea और Forgejo छोटे हैं और एक ही कंटेनर में चलते हैं। GitLab काफी बड़ा है और इसे कहीं अधिक मेमोरी की आवश्यकता होती है। cgit और Gitweb केवल read-only व्यू प्रकाशित करते हैं और इसके अलावा कुछ नहीं। सेल्फ-होस्टेड Git सर्वर के विकल्प और प्रत्येक को चलाने की लागत इनका उचित तुलनात्मक विवरण देता है।

स्वामित्व का अर्थ बैकअप भी है, और यहाँ यह हिस्सा वास्तव में आसान है, क्योंकि एक bare repository एक साधारण डायरेक्टरी होती है:

sudo tar czf /root/project-$(date +%F).tar.gz -C /home/git/repos project.git

उस फ़ाइल को सर्वर से बाहर कॉपी करें और रिपॉजिटरी पूरी तरह से रिकवर की जा सकती है। जो चीज़ मुफ्त में नहीं मिलती वह है अपटाइम, डिस्क स्पेस और सुरक्षा अपडेट। इसके पीछे कोई सपोर्ट टीम नहीं होती। ऐसे सर्वर के लिए जिसे किसी भी इनबाउंड कनेक्शन का जवाब नहीं देना चाहिए, किसी भी इनबाउंड पोर्ट को खोले बिना सर्विस प्रकाशित करना दूसरी दिशा है, और यह उस भरोसे को हटाने के बजाय टनल प्रदाता पर स्थानांतरित कर देता है।

अधिकांश लोगों के लिए इसका ईमानदार उत्तर दोनों का उपयोग करना है। GitHub सार्वजनिक कार्यों के लिए सहयोग उपकरण और मुफ्त CI रखता है। VPS एक ऐसी कॉपी रखता है जिसे कोई भी अकाउंट सस्पेंशन या आउटेज छीन नहीं सकता। जो पाठक पूरी चीज़ का स्वामित्व चाहते हैं, जिसमें रिव्यू इंटरफ़ेस भी शामिल है, उन्हें सेल्फ-होस्टेड Git सर्वर विकल्पों की तुलना से शुरुआत करनी चाहिए और वह चुनना चाहिए जो पहले से उपलब्ध हार्डवेयर से मेल खाता हो।

FAQ

क्या Git और GitHub एक ही चीज़ हैं?

नहीं। Git एक version control प्रोग्राम है जो कंप्यूटर पर install होता है, और यह बिना किसी account या network connection के काम करता है। GitHub एक कंपनी की hosted service है जो Git repository की एक copy store करती है और उसके साथ pull requests, issues और Actions जैसी सुविधाएँ जोड़ती है। GitHub से clone की गई repository में हर commit और हर branch सुरक्षित रहती है, भले ही GitHub बंद हो जाए, क्योंकि प्रत्येक clone में पूरा history मौजूद होता है।

क्या कोई छात्र बिना भुगतान किए GitHub का उपयोग कर सकता है?

हाँ। GitHub Free में private repositories शामिल हैं, और https://education.github.com/pack पर उपलब्ध GitHub Student Developer Pack में नामांकन सत्यापित होने के बाद और अधिक offers मिलते हैं। इसके लिए छात्र का नाम और वर्तमान सत्र दर्शाने वाले दस्तावेज़ या email की आवश्यकता होती है। इसमें शामिल Actions minutes और storage समय के साथ बदलते रहते हैं, इसलिए किसी guide में दिए गए आंकड़ों के बजाय https://github.com/pricing पर दी गई जानकारी को देखना बेहतर है। यह पृष्ठ अगस्त 2026 में लिखा गया था और इसमें जानबूझकर उन आंकड़ों को शामिल नहीं किया गया है।

क्या git commit बिना internet connection के काम करता है?

हाँ। Commit स्थानीय .git directory में objects लिखता है और एक branch pointer को move करता है। मशीन से कोई भी डेटा बाहर नहीं जाता है। केवल git push, git fetch, git pull और git clone के लिए network की आवश्यकता होती है, इसलिए internet न होने पर काम करने में बाधा नहीं आती, केवल उसे साझा करने में देरी होती है।

सर्वर पर repository का bare होना क्यों आवश्यक है?

क्योंकि एक सामान्य repository में एक branch checked out होती है, और Git किसी ऐसे working tree की files को बदलने से मना कर देता है जिसे कोई और edit कर रहा हो। ऐसी स्थिति में push को remote: error: refusing to update checked out branch: refs/heads/main के साथ reject कर दिया जाता है। git init --bare एक ऐसी repository बनाता है जिसमें कोई working tree नहीं होता, इसलिए किसी भी branch पर push स्वीकार कर लिया जाता है।

क्या VPS remote का नाम origin होना चाहिए?

Remote के नाम प्रत्येक clone के लिए स्थानीय होते हैं, इसलिए यह नियम के बजाय आदत की बात है। जिस remote को collaborators आधिकारिक मानते हैं, उसे origin रखने से साझा निर्देशों में भ्रम नहीं होता, और दूसरे remote को vps या backup नाम देने से git remote -v में उसका उद्देश्य स्पष्ट हो जाता है।