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 और अधिक लाभ जोड़ता है। GitHub वर्तमान नामांकन (enrolment) साबित करने वाला दस्तावेज़ मांगता है, जैसे कि स्कूल ID की फोटो जिसमें वर्तमान नामांकन तिथि हो, क्लास शेड्यूल, ट्रांसक्रिप्ट या नामांकन सत्यापन पत्र। जहाँ उसी स्कूल के हालिया आवेदकों ने शैक्षणिक ईमेल पते के साथ सत्यापन किया है, वहाँ GitHub एक शैक्षणिक ईमेल भी मांगता है, जिसे आवेदन करने से पहले खाते में जोड़ना और सत्यापित करना आवश्यक है। यदि स्कूल का ईमेल डोमेन आवेदन प्रक्रिया द्वारा पहचाना नहीं जाता है, तो मामला GitHub Education Support के पास जाता है। पैक के भीतर मिलने वाले ऑफ़र अन्य कंपनियों से आते हैं और सूची अक्सर बदलती रहती है, इसलिए पैक पेज ही इसका एकमात्र विश्वसनीय इन्वेंट्री है।

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

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

एक क्लाइंट चाहता है कि कोड उनके द्वारा नियंत्रित infrastructure पर रहे। कुछ अनुबंध और अधिकांश सार्वजनिक क्षेत्र के टेंडर यह निर्दिष्ट करते हैं कि source code और build artefacts कहाँ रखे जा सकते हैं। एक hosted account उस क्लॉज को पूरा नहीं कर सकता जो किसी सर्वर और देश का नाम लेता है। उस देश में एक VPS पर एक bare repository ऐसा कर सकती है, और डेवलपर उसी तरह काम करना जारी रखता है।

CI allowance समाप्त हो जाता है। Private repositories पर, आगे क्या होगा यह खाते के billing setup पर निर्भर करता है। यदि फाइल में कोई payment method नहीं है, तो निर्धारित कोटा समाप्त होने के बाद GitHub Actions के उपयोग को ब्लॉक कर देता है, जब तक कि अगले billing cycle की शुरुआत में कोटा रीसेट न हो जाए। यदि फाइल में payment method है, तो workflows चलते रहते हैं और अतिरिक्त मिनटों का शुल्क लिया जाता है, जब तक कि उपयोग को रोकने के लिए सेट किया गया बजट खर्च को सीमित न कर दे। किसी भी स्थिति में repository स्वयं अप्रभावित रहती है। एक समाधान GitHub को remote के रूप में बनाए रखता है और compute को कहीं सस्ता ले जाता है: VPS पर एक self-hosted GitHub Actions runner उन्हीं workflow फाइलों को एक ऐसी मशीन पर निष्पादित करता है जिसका बिल मिनट के बजाय महीने के आधार पर आता है। GitHub का billing documentation अक्टूबर 2026 तक self-hosted runner के उपयोग को मुफ्त बताता है।

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

एक ही खाते में एकमात्र कॉपी है। दो remotes का मतलब है दो स्वतंत्र विफलता मोड के साथ दो स्वतंत्र प्रतियां। दैनिक workflow में एक अतिरिक्त push के अलावा कुछ भी नहीं बदलता है।

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 प्रोग्राम है जो कंप्यूटर पर इंस्टॉल होता है, और यह बिना किसी खाते और बिना नेटवर्क कनेक्शन के काम करता है। GitHub एक कंपनी की hosted सेवा है जो Git repository की एक कॉपी स्टोर करती है और उसके चारों ओर pull requests, issues और Actions जोड़ती है। GitHub से clone की गई repository में हर commit और हर branch बनी रहती है, भले ही GitHub गायब हो जाए, क्योंकि प्रत्येक clone में पूरा इतिहास होता है।

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

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

क्या git commit बिना इंटरनेट कनेक्शन के काम करता है?

हाँ। Commit स्थानीय .git डायरेक्टरी में ऑब्जेक्ट्स लिखता है और एक branch पॉइंटर को मूव करता है। मशीन से कुछ भी बाहर नहीं जाता है। केवल git push, git fetch, git pull और git clone को नेटवर्क की आवश्यकता होती है, इसलिए आउटेज काम को करने के बजाय उसे साझा करने में देरी करता है।

सर्वर पर repository को bare क्यों होना चाहिए?

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

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

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