GitHub क्या है और Git vs GitHub में क्या अंतर है?

GitHub क्या है?

GitHub एक hosted service है जो Git repositories को store करती है और उनके चारों ओर एक वेबसाइट तैयार करती है। Git वह version control program है जो आपके अपने computer या server पर चलता है। GitHub, Git के ऊपर बनी एक कंपनी का product है, जो 2018 से Microsoft के स्वामित्व में है। आप हर दिन Git का उपयोग कर सकते हैं और कभी भी GitHub को open न करें। आप Git के बिना GitHub का उपयोग नहीं कर सकते।

यह अंतर उस क्षण महत्वपूर्ण हो जाता है जब आप एक VPS (virtual private server) के मालिक होते हैं। Git वह tool है जो आपकी config files और deploy scripts के इतिहास को record करता है। GitHub वह स्थान है जहाँ उस इतिहास की एक copy रहती है जब server पर वह उपलब्ध न हो, साथ ही यह builds और reviews चलाने की जगह भी है। यह guide एक empty folder से लेकर server पर deploy करने तक के एक उदाहरण का अनुसरण करती है, और हर नए शब्द को वहां परिभाषित करती है जहाँ आप पहली बार उससे मिलते हैं।

Git स्वयं क्या करता है

Git एक version control system है: यह समय के साथ एक directory की स्थिति को record करता है, ताकि आप देख सकें कि क्या बदला, कब बदला और क्यों बदला। इसे 2005 में Linux kernel के काम के लिए लिखा गया था। यह distributed है, जिसका अर्थ है कि repository की प्रत्येक copy में पूरा इतिहास मौजूद होता है। इसके design में कोई केंद्रीय सर्वर नहीं है। किसी सहकर्मी का laptop भी उतना ही पूर्ण copy है जितना कि कोई सर्वर।

इसे install करें और अपनी पहचान set करें। Git बिना नाम और email address के commit record करने से मना कर देता है, क्योंकि ये दोनों commit के भीतर ही लिखे जाते हैं।

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Ubuntu 24.04 पर, git --version, git version 2.43.0 print करता है। पिछले कुछ वर्षों का कोई भी release नीचे दी गई हर चीज़ के लिए समान व्यवहार करता है।

उदाहरण: आपके VPS डिप्लॉय फाइलों के लिए एक रिपॉजिटरी

एक repository, जिसे आमतौर पर संक्षिप्त में "repo" कहा जाता है, एक ऐसी डायरेक्टरी है जिसे Git मॉनिटर कर रहा होता है। यह तब रिपॉजिटरी बनती है जब आप git init रन करते हैं, जो इसके अंदर एक छिपी हुई .git फोल्डर बनाती है। वह फोल्डर ही असल में रिपॉजिटरी है। .git को डिलीट करें और आपके पास केवल एक सामान्य डायरेक्टरी बचेगी जिसमें कोई हिस्ट्री नहीं होगी।

mkdir vps-deploy && cd vps-deploy
git init -b main
printf '.env\n*.key\n' > .gitignore

-b main पहली ब्रांच का नाम main रखता है। इसे न लिखने पर Git डिफ़ॉल्ट ब्रांच नाम के बारे में एक लंबा संकेत (hint) प्रिंट करता है। .gitignore उन पाथ्स की सूची है जिन्हें Git को कभी ट्रैक नहीं करना चाहिए। पहले दिन ही अपनी सीक्रेट्स फाइल को इसमें लिख दें, क्योंकि एक बार कमिट की गई फाइल डिलीट करने के बाद भी हिस्ट्री में बनी रहती है, और उसे सही तरीके से हटाने का मतलब है उसके बाद के हर कमिट को फिर से लिखना।

Commits: इतिहास की इकाई

अब एक script जोड़ें और उसे record करें।

printf '#!/bin/sh\nsudo systemctl restart caddy\n' > restart.sh
git add restart.sh .gitignore
git commit -m "Add restart script and gitignore"
git log --oneline

git add एक बदलाव को staging area में ले जाता है, जो उन फाइलों की सूची है जिन्हें अगले commit में शामिल किया जाएगा। git commit उस सूची को एक प्रविष्टि (entry) के रूप में इतिहास में लिखता है। एक commit में हर tracked फाइल का snapshot, एक संदेश, लेखक, timestamp और पिछले commit का pointer होता है। git log --oneline प्रति commit एक पंक्ति प्रिंट करता है, जिसकी शुरुआत a1b2c3d जैसे एक छोटे hash से होती है। वह hash commit का नाम है, और लगभग हर Git command उसे स्वीकार करती है।

git add चरण को छोड़ें और git commit, no changes added to commit (use "git add" and/or "git commit -a") का उत्तर देता है। कुछ भी टूटा नहीं है। Git आपको बता रहा है कि staging area खाली है, इसलिए snapshot लेने के लिए कुछ भी नहीं है। जब भी आप उलझन में हों, तो चलाने के लिए git status सही command है: यह वर्तमान branch, staged बदलावों और उन फाइलों के नाम बताता है जिन्हें Git देख सकता है लेकिन track नहीं कर रहा है।

Branches: इतिहास की दूसरी पंक्ति

Branch एक commit की ओर इशारा करने वाला एक गतिशील pointer है। main एक branch है, और Git के लिए यह किसी भी तरह से विशेष नहीं है। इसे बनाने में कोई लागत नहीं आती, क्योंकि Git आपकी फाइलों को कॉपी करने के बजाय एक नया pointer लिखता है।

git switch -c add-backup
printf '#!/bin/sh\nrestic backup /srv\n' > backup.sh
git add backup.sh
git commit -m "Add nightly backup"
git switch main
ls

git switch main के बाद, सूची से backup.sh गायब है। कुछ भी डिलीट नहीं हुआ है। फाइल add-backup branch पर मौजूद है, और main में वह कभी थी ही नहीं, इसलिए जब आप move हुए तो Git ने उसे आपकी working directory से हटा दिया। यह बात हर किसी को एक बार हैरान करती है। git switch add-backup इसे वापस ले आता है।

Remotes: जहाँ अंततः GitHub दिखाई देता है

अब तक सब कुछ बिना किसी नेटवर्क के एक ही मशीन पर चल रहा था। एक remote उसी repository की दूसरी copy के लिए एक named URL होता है। GitHub आपके लिए उन copies में से एक को host करता है। मुख्य remote का पारंपरिक नाम origin है।

GitHub वेबसाइट के माध्यम से एक खाली repository बनाएँ, फिर उसे connect करें। यहाँ HTTPS के बजाय SSH को प्राथमिकता दें: एक SSH key वह file है जिसे आप नियंत्रित करते हैं, और यह personal access token की तरह expire नहीं होती है।

ssh-keygen -t ed25519 -C "vps-deploy"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com

प्रिंट की गई public key को अपने GitHub account के SSH keys page पर paste करें, फिर test को दोबारा चलाएँ। एक working key Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. का उत्तर देती है। GitHub आपको कोई shell नहीं देता है, इसलिए वह इनकार ही सफलता का संकेत है। git@github.com: Permission denied (publickey). का अर्थ है कि आपकी key कभी offer नहीं की गई या स्वीकार नहीं की गई, इसलिए जाँचें कि आपने .pub file को paste किया है, न कि उसके बगल वाली private key को।

git remote add origin git@github.com:yourname/vps-deploy.git
git push -u origin main

git push आपके commits को remote पर भेजता है। -u यह record करता है कि local main, remote main को track करता है, ताकि बाद में केवल git push पर्याप्त हो। git clone <url> एक नई मशीन पर इसका उल्टा काम करता है: यह पूरे repository को उसके history के साथ copy करता है और आपके लिए origin set करता है। एक HTTPS remote भी काम करता है, और यह उसी protocol पर चलता है जिस पर कोई भी web page, जो उन networks पर मदद करता है जो outbound port 22 को block करते हैं। यदि उस वाक्य को विस्तार से समझने की आवश्यकता है, तो HTTP request वास्तव में किस चीज़ से बना होता है इसकी कार्यप्रणाली को कवर करता है।

Pull requests, issues और forks: ये हिस्से GitHub हैं, Git नहीं

ऊपर दी गई हर चीज़ Git है, और यह किसी भी सर्वर पर काम करती है। नीचे दिए गए तीन शब्द GitHub के फीचर्स हैं। अन्य होस्ट इन्हें कॉपी करते हैं, और Git खुद इनके बारे में कुछ नहीं जानता।

एक pull request (PR) एक branch को दूसरी branch में merge करने का अनुरोध है, जिसे चर्चा के लिए एक पेज में लपेटा गया है। आप add-backup push करते हैं, main के विरुद्ध एक PR खोलते हैं, और साइट commit-दर-commit अंतर दिखाती है। लोग एक-एक लाइन पर टिप्पणी करते हैं। स्वचालित जाँचें branch के विरुद्ध pass या fail की रिपोर्ट देती हैं। merge पर क्लिक करें और GitHub अपनी कॉपी पर merge करता है, फिर main को अपडेट करता है। यह नाम मूल workflow से आया है, जहाँ आप एक maintainer से अपनी branch को उनकी branch में pull करने के लिए कहते थे।

एक issue किसी बग या कार्य के लिए एक क्रमांकित थ्रेड है। यह GitHub के डेटाबेस में रहता है, न कि आपके repository में, जिसे होस्ट चुनने से पहले जानना महत्वपूर्ण है: repo को clone करें तो आपके पास हर commit होगा, लेकिन एक भी issue नहीं। issues को बाहर निकालने का मतलब API को कॉल करना है।

एक fork किसी और की repository की आपकी अपनी सर्वर-साइड कॉपी है। आपके पास उस कॉपी पर write access होता है, आप उस पर एक branch push करते हैं, और अपनी कॉपी से उनकी कॉपी पर एक pull request खोलते हैं। इस तरह आप किसी ऐसे प्रोजेक्ट में योगदान करते हैं जिसके maintainers ने कभी आपके बारे में नहीं सुना। एक fork एक ऐसा clone है जो GitHub पर रहता है और याद रखता है कि वह कहाँ से आया था।

सॉफ्टवेयर इन तीनों को उसी API के माध्यम से पढ़ता है जिसका उपयोग एक व्यक्ति करता है। एक pull request review agent जिसे आप अपने सर्वर पर चलाते हैं नए PRs पर नज़र रखता है, diff को पढ़ता है, और लाइन पर टिप्पणियाँ पोस्ट करता है। repository के root में एक AGENTS.md फ़ाइल जैसे कन्वेंशन इसलिए मौजूद हैं क्योंकि अब एक repo को लोगों के साथ-साथ टूल्स द्वारा भी पढ़ा जाता है।

VPS मालिक के लिए GitHub वास्तव में क्या करता है

सर्वर से बाहर स्टोरेज का उपयोग करें। आपके deploy scripts और playbooks ऐसी जगह होने चाहिए जो उस सर्वर से अलग हो जिसे वे कॉन्फ़िगर करते हैं। VPS को एक ताज़ा image से फिर से बनाएँ, clone करें और चलाएँ। उस repository को private रखें और सर्वर को एक deploy key दें: यह एक SSH key है जो आपके पूरे account के बजाय केवल एक repository के लिए पंजीकृत होती है और इसे read-only पर सेट किया जाता है। एक लीक हुई read-only deploy key केवल एक repo को उजागर करती है। एक लीक हुई account key उन सभी चीजों को उजागर कर देती है जिन्हें आप push कर सकते हैं।

sudo git clone git@github.com:yourname/vps-deploy.git /srv/vps-deploy
cd /srv/vps-deploy
git pull --ff-only

--ff-only merge commit बनाने से इनकार करता है। ऐसे सर्वर पर जो केवल बदलावों को consume करता है, merge हमेशा एक दुर्घटना होती है, इसलिए यह flag एक भ्रमित करने वाले इतिहास को एक स्पष्ट त्रुटि में बदल देता है fatal: Not possible to fast-forward, aborting. सर्वर पर कुछ ऐसा बदल गया है जो नहीं बदलना चाहिए था। दोबारा pull करने से पहले उसे ढूँढें।

root के रूप में clone करें और फिर किसी अन्य user के रूप में Git चलाएँ, तो आपको fatal: detected dubious ownership in repository at '/srv/vps-deploy' मिलेगा। Git किसी अलग user के स्वामित्व वाली repository को पढ़ने से इनकार करता है, क्योंकि एक hostile .git/config Git को कमांड चलाने के लिए मजबूर कर सकता है। safe.directory exception जोड़ने के बजाय chown के साथ स्वामित्व (ownership) को ठीक करें, क्योंकि exception कारण को हटाए बिना केवल जाँच को शांत कर देता है।

GitHub Actions: build और deploy पाइपलाइन्स

Actions GitHub का CI/CD (continuous integration और continuous delivery) सिस्टम है। .github/workflows/ के अंतर्गत एक YAML फ़ाइल कमिट करें और आपके द्वारा निर्दिष्ट इवेंट होने पर GitHub उसे रन करता है।

name: check
on:
  push:
    branches: [main]
jobs:
  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck *.sh

यह फ़ाइल एक workflow है। एक job एक मशीन पर रन होती है। एक step एक कमांड या एक पब्लिश की गई action होती है। uses: किसी अन्य रिपॉजिटरी से एक action को पुल करता है और @v7 उसके मेजर वर्ज़न को पिन करता है (अगस्त 2026 तक actions/checkout के लिए v7 वर्तमान है)। हमेशा किसी चीज़ को पिन करें, क्योंकि बिना पिन की गई action का अर्थ है कि वह कोड जिसे आपने पढ़ा नहीं है, आपके secrets तक पहुँच के साथ रन हो रहा है।

runs-on: ubuntu-latest GitHub से एक नया वर्चुअल मशीन मांगता है, जिसे जॉब समाप्त होने पर हटा दिया जाता है। पब्लिक रिपॉजिटरी पर स्टैंडर्ड रनर्स निःशुल्क हैं, और अगस्त 2026 तक फ्री प्लान में प्राइवेट रिपॉजिटरी के लिए प्रति माह 2,000 मिनट शामिल हैं। उस आंकड़े पर बजट बनाने से पहले वर्तमान मूल्य निर्धारण पृष्ठ (pricing page) देखें।

Secrets को रिपॉजिटरी सेटिंग्स में स्टोर किया जाता है और ${{ secrets.DEPLOY_KEY }} के रूप में पढ़ा जाता है। एक फ़ॉर्क से पुल रिक्वेस्ट द्वारा ट्रिगर किए गए वर्कफ़्लो को रीड-ओनली टोकन मिलता है और उन secrets तक कोई पहुँच नहीं होती, क्योंकि अन्यथा कोई अजनबी एक ऐसी PR खोल सकता है जिसका एकमात्र काम उन्हें प्रिंट करना हो।

अपने VPS पर Actions runner चलाना

runs-on: self-hosted जॉब को आपके स्वामित्व वाली मशीन पर भेजता है। रिपॉजिटरी का runner सेटिंग्स पेज आपको एक डाउनलोड लाइन, रिपॉजिटरी का वेब एड्रेस और एक रजिस्ट्रेशन टोकन देता है जो एक घंटे के लिए मान्य होता है। इन अंतिम दो को REPO_URL और RUNNER_TOKEN में डालें, फिर सेटअप केवल तीन कमांड्स का है।

./config.sh --url "$REPO_URL" --token "$RUNNER_TOKEN"
sudo ./svc.sh install
sudo ./svc.sh start
./svc.sh status

svc.sh status को सर्विस को active दिखाना चाहिए और हाल की लॉग लाइन्स प्रदर्शित करनी चाहिए। runner GitHub के लिए एक आउटबाउंड HTTPS कनेक्शन खोलता है और काम मांगता है, इसलिए आपको इसके लिए कोई इनबाउंड पोर्ट खोलने की आवश्यकता नहीं है। svc.sh install systemd यूनिट लिखता है, और यह वह चरण है जिसे लोग छोड़ देते हैं: इसके बिना runner आपके SSH सेशन के साथ बंद हो जाता है और बाद की हर जॉब बिना किसी स्पष्टीकरण के कतार में पड़ी रहती है। VPS पर self-hosted runner का पूरा सेटअप उन सुरक्षा उपायों और सफाई के बारे में बताता है जिनकी एक लंबे समय तक चलने वाले runner को आवश्यकता होती है।

इसका लाभ यह है कि डिप्लॉयमेंट के लिए अब इंटरनेट से सुलभ इनबाउंड SSH की की आवश्यकता नहीं होती है, क्योंकि जॉब पहले से ही मशीन पर चल रही होती है। बिल्ड कैश भी रन के बीच में गर्म रहता है, और कोई मिनट मीटर नहीं चल रहा होता है।

एक चेतावनी अनिवार्य है। GitHub का अपना डॉक्यूमेंटेशन केवल प्राइवेट रिपॉजिटरी के लिए self-hosted runners की सिफारिश करता है, क्योंकि पब्लिक रिपॉजिटरी के फोर्क पुल रिक्वेस्ट खोलकर आपके runner पर खतरनाक कोड चला सकते हैं। runner उस ब्रांच की वर्कफ़्लो फ़ाइल में जो कुछ भी लिखा होता है, उसे निष्पादित करता है। एक प्राइवेट रिपॉजिटरी पर जहाँ आप नियंत्रित करते हैं कि कौन पुश कर सकता है, जोखिम कम है। एक पब्लिक रिपॉजिटरी पर, किसी भी self-hosted runner को ऐसी मशीन मानें जिस पर अजनबी कोड निष्पादित कर सकते हैं।

क्या आपको GitHub की बिल्कुल आवश्यकता है?

नहीं। Git एक मानक है, और GitHub केवल एक सुविधा है। Forgejo और Gitea self-hosted forges हैं। एक forge वह Git host है जिसमें issues और pull requests की सुविधा जुड़ी होती है। दोनों एक single Go binary के रूप में उपलब्ध हैं और एक छोटे VPS पर चल सकते हैं। Forgejo, Gitea का 2022 का एक fork है जो अब Codeberg को संचालित करता है। किसी repository को स्थानांतरित करना केवल एक command का काम है, क्योंकि wire protocol समान है।

git remote -v
git remote set-url origin git@git.example.com:you/vps-deploy.git
git push origin main

हर commit स्थानांतरित हो जाता है, क्योंकि हर clone में पहले से ही पूरा history मौजूद होता है। जो स्थानांतरित नहीं होता, वह GitHub द्वारा ऊपर बनाई गई परत है: issues और pull request threads। CI भी स्थानांतरित नहीं होता है। Forgejo का अपना Actions implementation है जो .forgejo/workflows/ से समान YAML पढ़ता है। इसका documentation सीमाओं के बारे में स्पष्ट है; यह कहता है कि GitHub Actions और Forgejo Actions एक समान नहीं हैं और चीजें तुरंत काम नहीं कर सकती हैं। इसके लिए अपने स्वयं के runner की भी आवश्यकता होती है। इस चरण को एक copy के रूप में नहीं, बल्कि एक port के रूप में प्लान करें।

ज्यादातर projects के बने रहने का वास्तविक कारण contributors हैं। Public code को वहीं होना चाहिए जहाँ लोगों के पास पहले से account हो। आपके private deploy scripts को वहाँ होने की आवश्यकता नहीं है। ये दो अलग-अलग निर्णय हैं, और आपको इनका उत्तर अलग-अलग देने की अनुमति है।

सबसे पहले क्या खराब होता है और error क्या कहता है

Push reject हो जाता है। आपको यह दिखाई देता है:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/vps-deploy.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

आपके अंतिम pull के बाद कुछ push किया गया है, अक्सर यह आपके द्वारा web editor में किया गया कोई बदलाव होता है। अपने commits को उनके ऊपर replay करने के लिए git pull --rebase चलाएँ, फिर दोबारा push करें। Shared branch पर git push --force का उपयोग करने से बचें, क्योंकि यह सर्वर पर मौजूद उस branch से अन्य commits को हटा देता है।

fatal: refusing to merge unrelated histories। आपने स्थानीय रूप से git init चलाया और GitHub को README के साथ repository बनाने दिया। दोनों histories में कोई भी commit समान नहीं है, इसलिए Git अनुमान नहीं लगा पाएगा। इसका सही समाधान यह है कि GitHub वाली copy को एक नए folder में clone करें और अपनी files को उसमें move कर दें।

error: src refspec main does not match any। जिस branch का आपने नाम लिया है वह यहाँ मौजूद नहीं है। आमतौर पर repository में अब तक शून्य commits होते हैं, या आपकी branch का नाम master होता है। git branch --show-current इसे ठीक कर देता है।

कोई secret commit में पहुँच गया है। credential को तुरंत rotate करें। इसे push किए जाने के क्षण से ही सार्वजनिक मानें, क्योंकि forks, mirrors और cached views में ऐसी copies होती हैं जिन्हें आप delete नहीं कर सकते।

FAQ

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

नहीं। Git एक version control प्रोग्राम है जिसे आप अपनी मशीन पर install करते हैं, और यह बिना किसी network या account के काम करता है। GitHub एक commercial hosted service है जो Git repositories को store करती है और उनके साथ web interface, issues, pull requests और CI जैसी सुविधाएँ जोड़ती है। Git को 2005 में release किया गया था और GitHub को 2008 में इसके ऊपर launch किया गया था। आप GitHub के बिना भी Git का उपयोग हमेशा के लिए कर सकते हैं। GitHub का हर feature मूल रूप से Git पर ही निर्भर करता है।

क्या अपने VPS पर Git का उपयोग करने के लिए मुझे GitHub account की आवश्यकता है?

नहीं। git init, git commit और git log बिना किसी remote configuration के भी सर्वर पर काम करते हैं, जो /etc files में बदलाव track करने या scripts deploy करने के लिए पर्याप्त है। account तब उपयोगी होता है जब आप history की एक ऐसी copy चाहते हैं जो सर्वर के खराब होने पर भी सुरक्षित रहे, या जब आप किसी दूसरी मशीन से उसे clone करना चाहते हैं। Forgejo और Gitea जैसे self-hosted forges आपके अपने hardware पर यही आवश्यकता पूरी करते हैं, और किसी अन्य box पर मौजूद bare repository की ओर इशारा करने वाला एक साधारण SSH remote बिना किसी forge software के भी काम करता है।

pull request क्या है?

pull request एक branch को दूसरी branch में merge करने का अनुरोध है, जिसके साथ एक discussion page जुड़ा होता है। आप एक branch push करते हैं, main के विरुद्ध PR open करते हैं, और host उस बदलाव को commit-दर-commit दिखाता है ताकि reviewers अलग-अलग lines पर comment कर सकें और automated checks pass या fail की report दे सकें। यह Git का नहीं, बल्कि GitHub का एक feature है, इसलिए Git में इसके लिए कोई command नहीं है। अन्य hosts भी इसी विचार को लागू करते हैं, जिसे कभी-कभी merge request कहा जाता है।

क्या मुझे अपने VPS पर GitHub Actions runner चलाना चाहिए?

private repository के लिए, अक्सर हाँ। job उस hardware पर चलती है जिसके लिए आप पहले से भुगतान कर रहे हैं, इसमें minutes की कोई सीमा नहीं होती, build cache बना रहता है, और deploy के लिए internet पर inbound SSH key expose करने की आवश्यकता नहीं होती, क्योंकि runner बाहर की ओर GitHub से connect होकर काम मांगता है। public repository के लिए, GitHub ऐसा न करने की सलाह देता है: कोई भी व्यक्ति आपकी repo को fork कर सकता है और एक ऐसी pull request open कर सकता है जिसका workflow आपकी मशीन पर code चला दे।

क्या मैं बाद में अपनी repositories को GitHub से हटा सकता हूँ?

code को, हाँ, आसानी से। हर clone में पूरी history होती है, इसलिए git remote set-url origin <new url> और उसके बाद push करने से वह सब कुछ move हो जाता है जो एक commit में होता है। जो पीछे रह जाता है वह वह layer है जिसका मालिक GitHub है: issues, pull request discussions और Actions history उसके database में रहते हैं, न कि आपके .git folder में। Migration tools API के माध्यम से issues को copy कर सकते हैं, और workflow files को आमतौर पर नए host के CI के लिए edit करने की आवश्यकता होती है। इसे ध्यान में रखना ही इस बात का तर्क है कि महत्वपूर्ण documentation को issue threads के बजाय repository के अंदर ही रखा जाए।