GitHub: शुरुआती से मास्टर तक: एक व्यापक गाइड

अगर आप GitHub से पैसे कमाना चाहते हैं, तो सबसे सीधा रास्ता जटिल नहीं है: लाइसेंस की अनुमति के तहत, मूल्यवान ओपन-सोर्स प्रोजेक्ट ढूंढें, डिप्लॉयमेंट, हिंदी डॉक्यूमेंटेशन और आफ्टर-सेल्स को एक सेवा में बदलें, और Xianyu जैसे प्लेटफॉर्म पर डिलीवरी बेचें।

हालांकि, असली पैसा इंफॉर्मेशन फिल्टरिंग और इम्प्लीमेंटेशन क्षमता से आता है। अगर आप AI करना चाहते हैं, FDE (फुल-स्टैक डेवलपमेंट इंजीनियर) बनना चाहते हैं, या खुद को OPC (वन पर्सन कंपनी) में बदलना चाहते हैं, तो कोड, डॉक्यूमेंटेशन, वर्जन और कोलैबोरेशन अंततः GitHub पर ही उतरेंगे।

भले ही आप क्रिएशन और सेल्फ-मीडिया कर रहे हों, GitHub पर बड़ी संख्या में टॉपिक सेलेक्शन टूल, ऑटोमेशन प्रोजेक्ट और कंटेंट प्रोडक्शन प्रोसेस मौजूद हैं। एक बार जब फाइलें बढ़ जाती हैं और AI बदलाव करता है, तो Git के बिना वर्जन मैनेज करना चीजों को जल्दी से नियंत्रण से बाहर कर सकता है। इसलिए, प्रोग्रामर को इसे सीखना चाहिए, और प्रोजेक्ट मैनेजर और कंटेंट क्रिएटर्स को भी; यह तय करता है कि क्या आप एक आइडिया को एक प्रबंधनीय, पुन: प्रयोग करने योग्य और डिलीवरेबल प्रोजेक्ट में बदल सकते हैं।

मैंने इस लेख को तैयार करने में आधे महीने से अधिक समय बिताया है, Git, GitHub, Commits, ब्रांच, PRs और सामान्य त्रुटियों को 0 से 1 तक प्रैक्टिस किया है। भविष्य के लाइव प्रसारण भी इसी प्रक्रिया का पालन करेंगे। आधिकारिक प्रसारण से पहले, मैं पहले इस ट्यूटोरियल को ओपन-सोर्स कर रहा हूं। आप इसे बुकमार्क कर सकते हैं या पूरी तरह से फॉलो कर सकते हैं।

1. Git और GitHub: कौन क्या मैनेज करता है?

Git एक वर्जन मैनेजमेंट टूल है जो आपके कंप्यूटर पर इंस्टॉल होता है। ऑफलाइन होने पर भी, आप कमिट कर सकते हैं, हिस्ट्री देख सकते हैं, ब्रांच बना सकते हैं और मर्ज कर सकते हैं। GitHub एक रिमोट रिपॉजिटरी और कोलैबोरेशन प्लेटफॉर्म है; यह Git द्वारा पुश किए गए कमिट को प्राप्त करता है और Issues, Pull Requests, Actions, कोड रिव्यू और परमिशन मैनेजमेंट प्रदान करता है।

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

सेव दबाने से केवल कंटेंट हार्ड ड्राइव पर लिखा जाता है। git add चुनने के लिए जिम्मेदार है, git commit स्थानीय रूप से एक वर्जन छोड़ता है, और git push इन कमिट को GitHub पर भेजता है।

इसलिए कमिट करने से पहले, diff चेक करें, इसे रन करें या टेस्ट करें; सफलतापूर्वक पुश करने के बाद, वेब पेज पर वापस जाकर डबल-चेक करें। इस तरह, अगर कोई समस्या आती है, तो आप तुरंत जान सकते हैं कि यह किस लेयर पर रुकी।

2. शुरू करने से पहले: केवल चार चीजें तैयार करें

आपको Git, एक GitHub अकाउंट, एक एडिटर और एक प्रैक्टिस प्रोजेक्ट चाहिए। एडिटर के लिए VS Code काफी है, और प्रोजेक्ट एक वेब पेज या Markdown डॉक्यूमेंट हो सकता है।

पहले, टर्मिनल में Git की पुष्टि करें:

1git --version

यह अभ्यास macOS और Git 2.49.0 का उपयोग करता है। Windows उपयोगकर्ता Git Bash या VS Code बिल्ट-इन टर्मिनल का उपयोग कर सकते हैं; नीचे दिए गए Git कमांड समान हैं।

इसके बाद, कमिट ऑथर कॉन्फ़िगर करें:

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

यह कमिट रिकॉर्ड में लिखी गई ऑथर जानकारी है; यह GitHub में लॉग इन करने के लिए जिम्मेदार नहीं है। यदि आप इसे केवल वर्तमान प्रैक्टिस प्रोजेक्ट के लिए कॉन्फ़िगर करना चाहते हैं, तो --global को --local से बदलें।

GitHub लॉगिन एक अलग मामला है। कमांड लाइन आमतौर पर तीन तरीकों का उपयोग करती है:

• GitHub CLI, ब्राउज़र के माध्यम से gh auth login से अधिकृत करना;
• HTTPS, Personal Access Token या क्रेडेंशियल मैनेजर का उपयोग करना;
• SSH, GitHub में एक पब्लिक की जोड़ना और बाद में की के माध्यम से प्रमाणित करना।

शुरुआती GitHub CLI या HTTPS चुन सकते हैं। HTTPS का उपयोग करते समय, यदि टर्मिनल पासवर्ड मांगता है, तो Token भरें; सामान्य अकाउंट पासवर्ड अब लागू नहीं होते हैं। Token को कमांड, रिमोट URL, README, चैट या स्क्रीनशॉट में न लिखें।

3. init करने में जल्दबाजी न करें: पुष्टि करें कि टर्मिनल वास्तव में कहां है

यह अभ्यास एक साधारण वेब पेज से शुरू होता है। इसे ब्राउज़र में खोला जा सकता है लेकिन इसमें अभी तक कोई Git हिस्ट्री नहीं है।

प्रोजेक्ट में तीन फाइलें हैं:

1index.html
2style.css
3.gitignore

VS Code में, "Open Folder" चुनें, सिर्फ एक HTML फाइल पर क्लिक न करें। फिर बिल्ट-इन टर्मिनल में रन करें:

1pwd
2ls

pwd वर्तमान डायरेक्टरी दिखाता है, और ls फाइलों को सूचीबद्ध करता है। index.html और style.css देखने के बाद ही आगे बढ़ें।

यह जांच बेवकूफी भरी लगती है, लेकिन यह सबसे परेशान करने वाली दुर्घटना को रोकती है: कोई डेस्कटॉप, डॉक्यूमेंट्स या यूजर होम डायरेक्टरी पर git init चलाता है, और फिर git add . हजारों अप्रासंगिक फाइलों को स्टेजिंग एरिया में डाल देता है। Git टूटा नहीं है; डायरेक्टरी गलत थी।

4. git init क्या करता है?

अब रिपॉजिटरी को इनिशियलाइज़ करें:

1git init -b main
2git status --short

git init -b main वर्तमान फोल्डर में एक .git डायरेक्टरी बनाता है और इनिशियल ब्रांच का नाम main रखता है। .git एक हिडन डायरेक्टरी है जहां कमिट, ब्रांच, स्टेजिंग एरिया और रिमोट एड्रेस जैसी जानकारी संग्रहीत होती है। प्रोजेक्ट फाइलें अपनी जगह पर रहती हैं; Git इसी क्षण से उनका निरीक्षण करना शुरू करता है।

स्क्रीनशॉट में ?? अनट्रैक की गई फाइलों को इंगित करता है। फाइलें मौजूद हैं, लेकिन Git ने अभी तक यह तय नहीं किया है कि उन्हें रिकॉर्ड करना है या नहीं।

रिपॉजिटरी रूट डायरेक्टरी की पुष्टि करने के लिए, आप रन कर सकते हैं:

1git rev-parse --show-toplevel

आउटपुट वर्तमान प्रोजेक्ट फोल्डर होना चाहिए। यदि यह fatal: not a git repository कहता है, तो पहले डायरेक्टरी चेक करें, फिर देखें कि क्या git init चलाया गया था।

5. पहला कमिट: एक विश्वसनीय शुरुआती बिंदु रखें

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

फिर .gitignore देखें। इस बार उपयोग की गई सामग्री है:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

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

पहले कमिट के लिए फाइलें चुनना शुरू करें:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

स्टेटस में A का मतलब Added है, जो दर्शाता है कि फाइल स्टेजिंग एरिया में प्रवेश कर गई है। git diff --cached --stat आपको बताएगा कि आप कितनी फाइलें कमिट करने की तैयारी कर रहे हैं और लगभग कितनी लाइनें बदली गईं। विशिष्ट सामग्री देखने के लिए, रन करें:

1git diff --cached

पुष्टि के बाद कमिट करें:

1git commit -m "chore: कैंपस AI भर्ती पेज को इनिशियलाइज़ करें"
2git log --oneline
3git status

एक कमिट को ऑथर, समय, विवरण और पैरेंट कमिट के साथ एक प्रोजेक्ट स्नैपशॉट के रूप में समझा जा सकता है। ffdf4ff इस कमिट हैश का छोटा संस्करण है; वर्तमान रिपॉजिटरी में इसका उपयोग करके वर्जन को सटीक रूप से ढूंढा जा सकता है।

feat, fix, docs, style, chore सामान्य कमिट प्रकार हैं, अनिवार्य Git सिंटैक्स नहीं। उपसर्ग से अधिक महत्वपूर्ण इसके बाद का हिंदी (या अंग्रेजी) विवरण है: क्या किया गया, किस ऑब्जेक्ट को संशोधित किया गया, और क्यों।

6. दूसरा कमिट: AI संशोधनों को समीक्षा के लिए ड्राफ्ट के रूप में मानें

इसके बाद, पेज पर एक "View Registration Method" बटन जोड़ें। AI प्रोग्रामिंग टूल का उपयोग करते समय, मैं प्रॉम्प्ट में सीमाएं लिखता हूं:

1Only modify index.html, add a "View Registration Method" link below the introduction text,
2linking to #apply within the page. Do not modify style.css, do not execute Git commits.
3Tell me which file was modified when finished.

मैन्युअल संशोधन भी सरल है:

1<a class="cta" href="#apply">View Registration Method</a>

AI कहता है कि यह हो गया, लेकिन अभी कमिट न करें। रन करें:

1git status --short
2git diff -- index.html
3git diff --check

git diff वर्कस्पेस में हुए बदलावों को दिखाता है जो अभी तक स्टेज नहीं हुए हैं। हरा + एक जोड़ी गई लाइन है, लाल - एक हटाई गई लाइन है। git diff --check का कोई आउटपुट नहीं है, जो दर्शाता है कि कोई स्पष्ट फॉर्मेटिंग समस्या जैसे ट्रेलिंग स्पेस नहीं मिली; यह आपके लिए यह जांच नहीं करेगा कि बटन क्लिक करने योग्य है या नहीं।

ब्राउज़र पर वापस जाएं और रिफ्रेश करें, बटन पर क्लिक करें, फिर विंडो को छोटा करें। पेज को रजिस्ट्रेशन एरिया तक स्क्रॉल करना चाहिए, और बटन और कार्ड संकीर्ण स्क्रीन पर भी सामान्य होने चाहिए।

टेस्ट पास होने के बाद ही कमिट करें:

1git add index.html
2git diff --cached
3git commit -m "feat: आवेदन विधियों को त्वरित देखने के लिए रजिस्ट्रेशन प्रविष्टि जोड़ें"
4git log --oneline -2

इस बिंदु पर, रिपॉजिटरी में दो स्पष्ट संस्करण हैं: शुरुआती पेज और रजिस्ट्रेशन बटन। यदि बाद में बटन में समस्या आती है, तो आप सीधे पता लगा सकते हैं कि किस कमिट ने इसे जोड़ा।

वैसे, दो diffs के बीच अंतर करें:

1git diff             # वर्कस्पेस और स्टेजिंग एरिया के बीच अंतर
2git diff --cached    # स्टेजिंग एरिया और सबसे हाल के कमिट के बीच अंतर

यदि git diff का कोई आउटपुट नहीं है, तो फाइल सहेजी नहीं गई हो सकती है, या यह पहले से ही स्टेज या कमिट हो चुकी हो सकती है। क्रम में git status, git diff --cached और git log की जांच करना बार-बार git add . टाइप करने से अधिक विश्वसनीय है।

7. ब्रांच: अनिश्चित बदलावों के लिए एक परीक्षण स्थान छोड़ें

बटन केवल एक लाइन जोड़ता है, इसलिए जोखिम छोटा है। पूरे थीम को बैंगनी से नारंगी में बदलना अच्छा लग सकता है या बेस्वाद लग सकता है; इस तरह का संशोधन ब्रांच के लिए उपयुक्त है।

1git switch -c experiment/warm-theme
2git branch --show-current

एक ब्रांच अवधारणात्मक रूप से एक नाम है जो एक निश्चित कमिट की ओर इशारा करता है। जब एक नई ब्रांच पहली बार बनाई जाती है, तो यह main के समान कमिट की ओर इशारा करती है, इसलिए फाइलें बिल्कुल समान होती हैं। केवल जब प्रयोगात्मक ब्रांच नए कमिट उत्पन्न करती है, तो दो लाइनें अलग हो जाती हैं।

आरेख में, नीला main अभी भी दूसरे कमिट की ओर इशारा करता है, जबकि नारंगी experiment पहले से ही तीसरे कमिट की ओर इशारा करता है। प्रोजेक्ट ने फाइलों के दो सेट डुप्लिकेट नहीं किए; केवल दो ब्रांच नामों के पॉइंटर बदले।

style.css में रंग वेरिएबल्स को संशोधित करें, पेज को रिफ्रेश करके पुष्टि करें, और फिर कमिट करें:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: प्रयोगात्मक ब्रांच में गर्म थीम आज़माएं"
5git log --oneline --graph --decorate --all

HEAD इंगित करता है कि आप वर्तमान में कहां खड़े हैं। स्क्रीनशॉट में, HEAD experiment/warm-theme की ओर इशारा करता है, जबकि main बटन कमिट पर बना हुआ है।

गर्म थीम रखने का निर्णय लें, main पर वापस स्विच करें और मर्ज करें:

1git switch main
2git merge experiment/warm-theme

यहां एक Fast-forward होता है क्योंकि प्रयोग के दौरान main में कोई नया कमिट नहीं था। Git सीधे main पॉइंटर को गर्म थीम कमिट पर आगे बढ़ाता है; बदलाव सफलतापूर्वक मर्ज हो गए हैं।

मर्ज की गई ब्रांच को सुरक्षित रूप से हटाया जा सकता है:

1git branch -d experiment/warm-theme

लोअरकेस -d जांचता है कि ब्रांच मर्ज हो गई है या नहीं। अपरकेस -D जबरदस्ती हटा देगा, और ब्रांच में वे कमिट जो मर्ज नहीं हुए हैं, अपने संदर्भ खो सकते हैं; इसे दैनिक सफाई कमांड के रूप में उपयोग न करें।

8. कॉन्फ्लिक्ट रहस्यमय नहीं हैं; Git बस आपके लिए चुनने की हिम्मत नहीं करता

कॉन्फ्लिक्ट को सत्यापित करने के लिए, मैंने रिपॉजिटरी को डुप्लिकेट किया। main ने मुख्य शीर्षक को "Let campus creativity be seen by more people" में बदल दिया, और feature ब्रांच ने उसी लाइन को "Turn an idea into a truly usable work" में बदल दिया। मर्ज के दौरान Git रुक गया:

कॉन्फ्लिक्ट मार्कर तीन भागों में विभाजित हैं:

1<<<<<<< HEAD
2वर्तमान ब्रांच की सामग्री
3=======
4मर्ज की जाने वाली ब्रांच की सामग्री
5>>>>>>> feature/rewrite-heading

हैंडलिंग विधि फाइल को संपादित करना, अंतिम वांछित टेक्स्ट छोड़ना, तीनों सेट मार्करों को हटाना, इसका परीक्षण करना, और फिर रन करना है:

1git add index.html
2git commit

यदि आप उस समय इसे हैंडल नहीं करना चाहते हैं, तो आप मर्ज को रद्द कर सकते हैं:

1git merge --abort

कॉन्फ्लिक्ट का मतलब है कि दो लोगों या दो Agents ने एक ही स्थान के लिए अलग-अलग उत्तर दिए, और Git अपने आप चुन नहीं सकता।

9. लोकल रिपॉजिटरी को GitHub पर भेजना

प्रोजेक्ट में पहले से ही एक लोकल हिस्ट्री है; अब GitHub पर एक रिपॉजिटरी बनाएं। ऊपरी दाएं कोने में + पर क्लिक करें, "New repository" चुनें, और रिपॉजिटरी का नाम भरें, उदाहरण के लिए:

1campus-ai-demo

पहले अभ्यास के लिए, इसे Private पर सेट करने की अनुशंसा की जाती है। चूंकि स्थानीय रूप से पहले से ही README, .gitignore और कमिट हिस्ट्री है, नई GitHub रिपॉजिटरी को खाली रखें; वेब साइड पर README, लाइसेंस या .gitignore को इनिशियलाइज़ न करें। अन्यथा, स्थानीय और रिमोट में प्रत्येक के पास प्रारंभिक हिस्ट्री का एक टुकड़ा होगा, और पहले पुश के लिए दोनों पक्षों के बीच संबंध को संभालना होगा। GitHub का आधिकारिक "Adding locally hosted code" भी स्पष्ट रूप से इसकी याद दिलाता है।

HTTPS एड्रेस कॉपी करें:

1https://github.com/YourUsername/campus-ai-demo.git

प्रोजेक्ट टर्मिनल पर वापस जाएं:

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin रिमोट एड्रेस का एक उपनाम है; यह अन्य नामों के साथ काम कर सकता है, लेकिन समुदाय आदतन मुख्य रिमोट को origin कहता है। -u स्थानीय main और origin/main के बीच एक ट्रैकिंग संबंध स्थापित करेगा; बाद के ऑपरेशन आमतौर पर केवल git push चलाते हैं।

नीचे दिए गए टर्मिनल आरेख ने push और clone के माध्यम से चलाने के लिए एक स्थानीय बेयर रिपॉजिटरी का उपयोग किया, इसलिए इसने मौजूदा GitHub अकाउंट को नहीं बदला। GitHub पर स्विच करते समय, बस origin URL बदलें; Git के लिए कमिट पास करने और ट्रैकिंग संबंध स्थापित करने का तर्क समान है।

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

10. पहली बार GitHub रिपॉजिटरी पढ़ना: पेज पर इन चीजों को कैसे पढ़ें

नीचे आधिकारिक GitHub डॉक्यूमेंटेशन रिपॉजिटरी का वास्तविक पेज है, जिसका स्क्रीनशॉट 15 अगस्त, 2026 को लिया गया है।

रिपॉजिटरी खोलते समय, पहले इन स्थानों को देखें:

• Code: फाइलें, डायरेक्टरी, ब्रांच और कमिट;
• Issues: बग, आवश्यकताएं, कार्य और चर्चाएं;
• Pull requests: समीक्षा या मर्ज की प्रतीक्षा कर रहे बदलाव;
• Actions: स्वचालित परीक्षण, निर्माण और डिप्लॉयमेंट;
• Security: सुरक्षा नीतियां और कमजोरियों से संबंधित कार्य;
• Insights: योगदान, ट्रैफ़िक और रिपॉजिटरी गतिविधि;
• README: प्रोजेक्ट परिचय और उपयोग प्रविष्टि;
• LICENSE: इसका उपयोग, संशोधन और वितरण कैसे किया जाता है।

किसी अपरिचित प्रोजेक्ट को पढ़ते समय, पहले Stars पर घूरें नहीं। पहले पांच प्रश्नों के उत्तर दें: यह किस समस्या का समाधान करता है, यह कैसे चलता है, इसकी क्या निर्भरताएं हैं, क्या इसका हाल ही में रखरखाव किया गया है, और लाइसेंस मुझे क्या करने की अनुमति देता है। Stars ध्यान को दर्शाते हैं; वे आपके लिए सुरक्षा, अनुकूलता या प्राधिकरण की जांच नहीं करते।

11. clone, fetch, pull, push: चार दिशाओं को भ्रमित न करें

पहली बार रिमोट रिपॉजिटरी को अपने कंप्यूटर पर लाना:

1git clone https://github.com/OWNER/REPO.git

Clone फाइलें, कमिट हिस्ट्री और रिमोट कॉन्फ़िगरेशन वापस लाता है, आमतौर पर स्वचालित रूप से रिमोट का नाम origin रखता है। ZIP डाउनलोड करने से केवल उस समय फाइलों का एक स्नैपशॉट मिलता है, बिना पूर्ण हिस्ट्री के, और रिमोट संबंध स्थापित नहीं होगा।

बाद में आमतौर पर उपयोग की जाने वाली तीन क्रियाएं हैं:

1git fetch origin   # रिमोट जानकारी डाउनलोड करें, वर्तमान कार्य फाइलों को नहीं बदलता
2git pull           # fetch करें और फिर वर्तमान ब्रांच में एकीकृत करें
3git push           # स्थानीय कमिट को रिमोट पर भेजें

पहले यह देखने के लिए कि रिमोट पर क्या हुआ, आप कर सकते हैं:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

जब पुष्टि हो जाए कि स्थानीय रूप से कोई विचलन नहीं है और आप केवल फास्ट-फॉरवर्ड अपडेट स्वीकार करना चाहते हैं:

1git pull --ff-only

pull पहले fetch करेगा, और फिर कॉन्फ़िगरेशन के आधार पर merge या rebase करेगा। टीमों को पहले सहयोग से पहले एकीकरण विधि पर सहमत होना चाहिए, और विचलन होने पर समस्याओं को सुलझाने के लिए force push पर निर्भर न हों।

12. व्यक्तिगत रिपॉजिटरी से GitHub सहयोग तक

Pull Request एक मर्ज प्रस्ताव है और जहां सहयोग होता है। चर्चा, कोड रिव्यू और स्वचालित जांच सभी बदलावों के एक ही सेट के आसपास घूमते हैं, और पुष्टि के बाद ही इसे main में मर्ज किया जाता है।

मान लें कि Issue "Add event time description" है, तो स्थानीय ऑपरेशन इस तरह किए जा सकते हैं:

1git switch -c feat/event-time
2# पेज को संशोधित और परीक्षण करें
3git add index.html
4git commit -m "feat: इवेंट समय विवरण जोड़ें"
5git push -u origin feat/event-time

पुश करने के बाद, GitHub आमतौर पर Pull Request बनाने का संकेत देता है। PR एक मर्ज प्रस्ताव है जो विवरण, कमिट, फाइल अंतर, टिप्पणियां, समीक्षाएं और स्वचालित जांच प्रदर्शित करता है। यह बनाए जाने पर स्वचालित रूप से main में प्रवेश नहीं करेगा।

एक PR जिसे लोग समीक्षा करने को तैयार हैं, उसे कम से कम तीन चीजें समझानी चाहिए: क्या बदला गया, क्यों बदला गया, और इसे कैसे सत्यापित किया जाए। बदलाव जितने अधिक केंद्रित होंगे, समीक्षकों के लिए समस्याओं को देखना उतना ही आसान होगा।

एक ही टीम में, यदि आपके पास रिपॉजिटरी में लिखने की पहुंच है, तो आप सीधे एक ब्रांच से PR भेज सकते हैं। किसी अपरिचित ओपन-सोर्स प्रोजेक्ट में योगदान करते समय, सामान्य प्रथा पहले इसे अपने अकाउंट में Fork करना है, और फिर अपने Fork को clone करना है:

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

यहां आमतौर पर दो रिमोट होते हैं:

1origin    आपका अपना Fork
2upstream  मूल लेखक की रिपॉजिटरी

मूल प्रोजेक्ट को सिंक्रोनाइज़ करें:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

फिर एक नई ब्रांच में संशोधन पूरा करें, अपने Fork पर पुश करें, और फिर upstream को एक PR भेजें। Fork, clone और ब्रांच तीन अलग-अलग चीजों को हल करते हैं: Fork GitHub पर रिपॉजिटरी स्पेस का एक सेट है, clone रिपॉजिटरी को स्थानीय रूप से लाता है, और ब्रांच एक रिपॉजिटरी के भीतर एक डेवलपमेंट लाइन है।

13. README और LICENSE तय करते हैं कि क्या अन्य लोग इसका उपयोग करने की हिम्मत करेंगे

README को कम से कम इन सवालों के जवाब देने चाहिए:

1. प्रोजेक्ट क्या है;
2. यह किस समस्या का समाधान करता है;
3. इसे कैसे इंस्टॉल या रन करें;
4. यह वर्तमान में किस हद तक पूरा हुआ है;
5. मुख्य फाइलें कहां हैं;
6. लेखक, सामग्री और उद्धरण स्रोत कौन हैं।

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

सार्वजनिक रिपॉजिटरी स्वचालित रूप से ओपन-सोर्स लाइसेंस प्राप्त करने के बराबर नहीं हैं। GitHub का आधिकारिक लाइसेंस स्पष्टीकरण स्पष्ट रूप से कहता है: जब कोई लाइसेंस नहीं है, तो डिफ़ॉल्ट कॉपीराइट नियम अभी भी लागू होते हैं, और लेखक कॉपी, वितरण और व्युत्पन्न कार्य बनाने के अधिकार बरकरार रखता है। सार्वजनिक का मतलब है कि अन्य लोग इसे देख सकते हैं और GitHub की सेवा की शर्तों के अनुसार इसे Fork कर सकते हैं; कोड को अपने सार्वजनिक या व्यावसायिक प्रोजेक्ट में ले जाने के लिए, आपको रिपॉजिटरी में LICENSE को भी देखना होगा।

MIT, Apache-2.0, GPL, आदि के अलग-अलग दायित्व हैं। व्यावसायिक उपयोग, पुनर्वितरण या मिश्रित लाइसेंस का सामना करते समय, पूरी फाइल पढ़ें और यदि आवश्यक हो तो किसी पेशेवर से परामर्श करें; सिर्फ AI से यह न पूछें "क्या मैं इसका व्यावसायिक उपयोग कर सकता हूं?"

14. गलती करने के बाद: निर्धारित करें कि बदलाव किस लेयर में है

पछतावे की दवा को स्थिति के अनुसार चुना जाना चाहिए।

गलत फाइल स्टेज कर दी लेकिन फाइल सामग्री रखना चाहते हैं:

1git restore --staged filename

सबसे हाल का कमिट संदेश गलत लिखा गया था और अभी तक पुश नहीं हुआ है:

1git commit --amend -m "नया कमिट संदेश"

साझा ब्रांच पर एक कमिट को रद्द करने की आवश्यकता है:

1git revert commit_hash

revert एक नया रिवर्स कमिट उत्पन्न करेगा, और पुरानी हिस्ट्री दिखाई देती रहेगी, जो उन ब्रांच के लिए उपयुक्त है जो पहले ही पुश हो चुकी हैं और कई लोगों द्वारा उपयोग की जाती हैं।

git restore filename उन संशोधनों को त्याग देगा जो कमिट नहीं हुए हैं; git reset --hard कमिट, स्टेजिंग एरिया और वर्कस्पेस सभी को एक निर्दिष्ट स्थिति में वापस लाएगा; git push --force रिमोट कमिट को ओवरराइट कर सकता है। इन तीन प्रकार के ऑपरेशनों के लिए निष्पादन से पहले लक्ष्य की पुष्टि और बैकअप की आवश्यकता होती है; उन्हें शून्य-आधार चरण में सामान्य मरम्मत बटन के रूप में न मानें।

15. आठ सबसे आम त्रुटियां: इस क्रम में जांचें

1. fatal: not a git repository

1pwd
2ls
3git status

आमतौर पर, डायरेक्टरी गलत है, या वर्तमान प्रोजेक्ट में अभी तक git init नहीं किया गया है।

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

जांचें कि क्या फाइल सहेजी गई है, क्या आपने दूसरी प्रति संशोधित की है, और क्या बदलाव पहले ही कमिट हो चुके हैं:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin CorrectGitHubAddress

5. src refspec main does not match any

हो सकता है कि रिपॉजिटरी में अभी तक कोई कमिट न हो, या वर्तमान ब्रांच का नाम main न हो:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

रिमोट URL, रिपॉजिटरी स्वामित्व, अकाउंट अनुमतियां और प्रमाणीकरण विधि की जांच करें। समस्या निवारण के लिए Token दूसरों को न भेजें।

7. rejected non-fast-forward

रिमोट पर कमिट हैं जो स्थानीय रूप से नहीं हैं। पहले fetch करें और अंतर देखें; सिर्फ force push न करें:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

UU फाइलों को खोजने के लिए git status चलाएं, मैन्युअल रूप से अंतिम सामग्री निर्धारित करें, परीक्षण करें, फिर add और commit करें; यदि अभी हैंडल नहीं कर रहे हैं, तो git merge --abort।

जब कोई छात्र या सहकर्मी सिर्फ़ यह कहता है कि "Git खराब हो गया है", तो उनसे ये पाँच आउटपुट माँगें:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

फिर ऑपरेटिंग सिस्टम, अभी-अभी निष्पादित पूरा कमांड, और पूरा एरर मैसेज जोड़ें। अधिकांश समस्याएँ जल्दी ही किसी एक लेयर में आ जाएँगी: डायरेक्टरी, स्थिति, पहचान, रिमोट एड्रेस, या अनुमति।

16. AI युग में, Git एक स्वीकृति प्रणाली की तरह अधिक है

AI आपके लिए कमांड टाइप कर सकता है, लेकिन यह स्वचालित रूप से नहीं जान सकता कि कौन से संशोधन व्यावसायिक इरादों को पूरा करते हैं। यदि कोई प्रॉम्प्ट 20 फ़ाइलों को बदलता है और आप diff नहीं देखते हैं, प्रोजेक्ट नहीं चलाते हैं, और कुंजियों की जाँच नहीं करते हैं, तो Git केवल ईमानदारी से इस गड़बड़ी को रिकॉर्ड करेगा।

एक अधिक स्थिर तरीका कार्य को संकीर्ण करना और मनुष्य को स्वीकृति की स्थिति में रखना है। दायरे, अंतर, परीक्षणों और कुंजी जाँचों के सभी पास हो जाने के बाद, मनुष्य तय करता है कि क्या ये संशोधन एक कमिट बन सकते हैं।

AI को Git संचालित करने देते समय, सीमाएँ भी दें:

1कृपया पहले git status और git diff जाँचें, और केवल वर्तमान परिवर्तनों का सारांश दें।
2किसी भी अनकमिटेड सामग्री को न छोड़ें, reset --hard, clean, या force push निष्पादित न करें।
3संशोधन पूरा करने के बाद सत्यापन परिणाम प्रदान करें, स्वचालित रूप से कमिट या push न करें।

अब कमांड याद रखना उतना महत्वपूर्ण नहीं रह गया है। आपको स्थिति पढ़ने में सक्षम होना चाहिए, यह जानना चाहिए कि AI ने क्या हिलाया, यह निर्णय करना चाहिए कि क्या सत्यापन पर्याप्त है, और जब खतरनाक संचालन दिखाई दें तो रुकने का आदेश देना चाहिए।

17. पूरी प्रक्रिया फिर से चलाएँ

1# 1. स्थान की पुष्टि करें
2pwd
3ls
4
5# 2. आरंभ करें
6git init -b main
7git status
8
9# 3. पहला कमिट
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: Initialize project"
13
14# 4. संशोधित करें, जाँचें, परीक्षण करें, फिर से कमिट करें
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: Add registration entry"
20
21# 5. शाखा प्रयोग
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: Experiment with warm theme"
25git switch main
26git merge experiment/warm-theme
27
28# 6. GitHub से कनेक्ट करें
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. अंतिम जाँच
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

जब आप समझा सकते हैं कि प्रत्येक कमांड ने कौन सी लेयर बदली, और स्वतंत्र रूप से गलत डायरेक्टरी, स्टेजिंग त्रुटि और मर्ज कॉन्फ्लिक्ट को संभाल सकते हैं, तब GitHub सिर्फ़ कोड स्टोर करने वाली एक वेबसाइट नहीं रह जाता है। आप पहले से ही व्यक्तिगत प्रोजेक्ट्स को ऐसे रिपॉजिटरी में बदलने में सक्षम हैं जिनकी समीक्षा, ऑडिट और सहयोग किया जा सकता है।

अगला कदम कमांड इकट्ठा करना जारी रखने की आवश्यकता नहीं है। एक वास्तविक छोटा प्रोजेक्ट खोजें और इसे लगातार 7 दिनों तक करें: हर दिन केवल एक छोटा संशोधन पूरा करें, diff देखें, परीक्षण करें, कमिट करें, और फिर GitHub पर push करें। कमिट हिस्ट्री धीरे-धीरे इस सेट को आपकी कार्य आदत में बदल देगी।

मैं माइल्स हूँ, एक AI एल्गोरिदम विशेषज्ञ जो बड़ी कंपनी से FDE में आया हूँ। मैंने एल्गोरिदम R&D, ऑप्टिमाइज़ेशन डिप्लॉयमेंट और कॉर्पोरेट प्रशिक्षण किया है। मुझे फ़ॉलो करें @miles_mazy एक साथ बढ़ें, एक साथ पैसा कमाएँ।