You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
337 lines
37 KiB
337 lines
37 KiB
<!--
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
{
|
|
"original_hash": "05666cecb8983a72cf0ce1d18932b5b7",
|
|
"translation_date": "2025-08-24T12:51:22+00:00",
|
|
"source_file": "1-getting-started-lessons/2-github-basics/README.md",
|
|
"language_code": "hi"
|
|
}
|
|
-->
|
|
# GitHub का परिचय
|
|
|
|
यह पाठ GitHub की मूल बातें कवर करता है, जो आपके कोड को होस्ट और प्रबंधित करने के लिए एक प्लेटफ़ॉर्म है।
|
|
|
|
|
|
> स्केच नोट [Tomomi Imura](https://twitter.com/girlie_mac) द्वारा
|
|
|
|
## प्री-लेक्चर क्विज़
|
|
[प्री-लेक्चर क्विज़](https://ff-quizzes.netlify.app/web/quiz/3)
|
|
|
|
## परिचय
|
|
|
|
इस पाठ में, हम निम्नलिखित विषयों को कवर करेंगे:
|
|
|
|
- आपके मशीन पर किए गए कार्य को ट्रैक करना
|
|
- दूसरों के साथ प्रोजेक्ट्स पर काम करना
|
|
- ओपन सोर्स सॉफ़्टवेयर में योगदान कैसे करें
|
|
|
|
### आवश्यकताएँ
|
|
|
|
शुरू करने से पहले, आपको यह जांचना होगा कि Git इंस्टॉल है या नहीं। टर्मिनल में टाइप करें:
|
|
`git --version`
|
|
|
|
यदि Git इंस्टॉल नहीं है, तो [Git डाउनलोड करें](https://git-scm.com/downloads)। फिर, अपने स्थानीय Git प्रोफ़ाइल को टर्मिनल में सेटअप करें:
|
|
* `git config --global user.name "your-name"`
|
|
* `git config --global user.email "your-email"`
|
|
|
|
यह जांचने के लिए कि Git पहले से कॉन्फ़िगर है या नहीं, आप टाइप कर सकते हैं:
|
|
`git config --list`
|
|
|
|
आपको एक GitHub अकाउंट, एक कोड एडिटर (जैसे Visual Studio Code), और अपना टर्मिनल (या: कमांड प्रॉम्प्ट) खोलने की आवश्यकता होगी।
|
|
|
|
[github.com](https://github.com/) पर जाएं और यदि आपने पहले से अकाउंट नहीं बनाया है तो एक अकाउंट बनाएं, या लॉग इन करें और अपनी प्रोफ़ाइल भरें।
|
|
|
|
✅ GitHub दुनिया में एकमात्र कोड रिपॉजिटरी नहीं है; अन्य भी हैं, लेकिन GitHub सबसे प्रसिद्ध है।
|
|
|
|
### तैयारी
|
|
|
|
आपको अपने स्थानीय मशीन (लैपटॉप या पीसी) पर एक कोड प्रोजेक्ट के साथ एक फ़ोल्डर और GitHub पर एक सार्वजनिक रिपॉजिटरी की आवश्यकता होगी, जो दूसरों के प्रोजेक्ट्स में योगदान करने के तरीके का उदाहरण देगा।
|
|
|
|
---
|
|
|
|
## कोड प्रबंधन
|
|
|
|
मान लें कि आपके पास स्थानीय रूप से एक कोड प्रोजेक्ट के साथ एक फ़ोल्डर है और आप Git - वर्जन कंट्रोल सिस्टम का उपयोग करके अपनी प्रगति को ट्रैक करना शुरू करना चाहते हैं। कुछ लोग Git का उपयोग करने की तुलना भविष्य के स्वयं को प्रेम पत्र लिखने से करते हैं। जब आप अच्छे "कमिट संदेश" लिखते हैं, तो आप दिनों, हफ्तों या महीनों बाद यह याद कर पाएंगे कि आपने कोई निर्णय क्यों लिया था, या किसी बदलाव को "रोलबैक" कर सकते हैं।
|
|
|
|
### कार्य: एक रिपॉजिटरी बनाएं और कोड कमिट करें
|
|
|
|
> वीडियो देखें
|
|
>
|
|
> [](https://www.youtube.com/watch?v=9R31OUPpxU4)
|
|
|
|
1. **GitHub पर रिपॉजिटरी बनाएं**। GitHub.com पर, रिपॉजिटरी टैब में, या टॉप-राइट नेविगेशन बार से, **नया रिपो** बटन खोजें।
|
|
|
|
1. अपनी रिपॉजिटरी (फ़ोल्डर) को एक नाम दें।
|
|
1. **रिपॉजिटरी बनाएं** चुनें।
|
|
|
|
1. **अपने कार्य फ़ोल्डर पर जाएं**। अपने टर्मिनल में, उस फ़ोल्डर (जिसे डायरेक्टरी भी कहा जाता है) पर स्विच करें जिसे आप ट्रैक करना शुरू करना चाहते हैं। टाइप करें:
|
|
|
|
```bash
|
|
cd [name of your folder]
|
|
```
|
|
|
|
1. **Git रिपॉजिटरी प्रारंभ करें**। अपने प्रोजेक्ट में टाइप करें:
|
|
|
|
```bash
|
|
git init
|
|
```
|
|
|
|
1. **स्टेटस जांचें**। अपनी रिपॉजिटरी की स्थिति जांचने के लिए टाइप करें:
|
|
|
|
```bash
|
|
git status
|
|
```
|
|
|
|
आउटपुट कुछ इस तरह दिख सकता है:
|
|
|
|
```output
|
|
Changes not staged for commit:
|
|
(use "git add <file>..." to update what will be committed)
|
|
(use "git checkout -- <file>..." to discard changes in working directory)
|
|
|
|
modified: file.txt
|
|
modified: file2.txt
|
|
```
|
|
|
|
आमतौर पर `git status` कमांड आपको यह बताती है कि कौन सी फाइलें _सेव_ करने के लिए तैयार हैं या उनमें बदलाव हैं जिन्हें आप स्थायी बनाना चाहते हैं।
|
|
|
|
1. **सभी फाइलें ट्रैकिंग के लिए जोड़ें**
|
|
इसे फाइलों को स्टेजिंग एरिया में जोड़ना भी कहा जाता है।
|
|
|
|
```bash
|
|
git add .
|
|
```
|
|
|
|
`git add` और `.` तर्क इंगित करता है कि आपकी सभी फाइलें और बदलाव ट्रैकिंग के लिए हैं।
|
|
|
|
1. **चयनित फाइलें ट्रैकिंग के लिए जोड़ें**
|
|
|
|
```bash
|
|
git add [file or folder name]
|
|
```
|
|
|
|
यह हमें केवल चयनित फाइलों को स्टेजिंग एरिया में जोड़ने में मदद करता है जब हम सभी फाइलों को एक साथ कमिट नहीं करना चाहते।
|
|
|
|
1. **सभी फाइलें अनस्टेज करें**
|
|
|
|
```bash
|
|
git reset
|
|
```
|
|
|
|
यह कमांड हमें एक बार में सभी फाइलों को अनस्टेज करने में मदद करता है।
|
|
|
|
1. **एक विशेष फाइल को अनस्टेज करें**
|
|
|
|
```bash
|
|
git reset [file or folder name]
|
|
```
|
|
|
|
यह कमांड हमें केवल एक विशेष फाइल को अनस्टेज करने में मदद करता है जिसे हम अगले कमिट में शामिल नहीं करना चाहते।
|
|
|
|
1. **अपना कार्य स्थायी बनाएं**। इस बिंदु पर आपने फाइलों को तथाकथित _स्टेजिंग एरिया_ में जोड़ दिया है। यह वह जगह है जहां Git आपकी फाइलों को ट्रैक कर रहा है। बदलाव को स्थायी बनाने के लिए आपको फाइलों को _कमिट_ करना होगा। ऐसा करने के लिए आप `git commit` कमांड का उपयोग करके एक _कमिट_ बनाते हैं। एक _कमिट_ आपके रिपॉजिटरी के इतिहास में एक सेविंग पॉइंट का प्रतिनिधित्व करता है। टाइप करें:
|
|
|
|
```bash
|
|
git commit -m "first commit"
|
|
```
|
|
|
|
यह आपकी सभी फाइलों को कमिट करता है, संदेश "पहला कमिट" जोड़ते हुए। भविष्य के कमिट संदेशों के लिए आप अपने विवरण में अधिक वर्णनात्मक होना चाहेंगे ताकि यह स्पष्ट हो सके कि आपने किस प्रकार का बदलाव किया है।
|
|
|
|
1. **अपने स्थानीय Git रिपो को GitHub से कनेक्ट करें**। एक Git रिपो आपके मशीन पर अच्छा है लेकिन किसी बिंदु पर आप अपनी फाइलों का बैकअप कहीं रखना चाहेंगे और अन्य लोगों को अपने रिपो पर काम करने के लिए आमंत्रित करना चाहेंगे। ऐसा करने के लिए एक शानदार जगह GitHub है। याद रखें कि हमने पहले ही GitHub पर एक रिपो बनाया है, इसलिए हमें केवल अपने स्थानीय Git रिपो को GitHub से कनेक्ट करना है। कमांड `git remote add` यही करेगा। टाइप करें:
|
|
|
|
> नोट, कमांड टाइप करने से पहले अपने GitHub रिपो पेज पर जाएं और रिपॉजिटरी URL खोजें। आप इसे नीचे दिए गए कमांड में उपयोग करेंगे। ```https://github.com/username/repository_name.git``` को अपने GitHub URL से बदलें।
|
|
|
|
```bash
|
|
git remote add origin https://github.com/username/repository_name.git
|
|
```
|
|
|
|
यह एक _रिमोट_, या कनेक्शन, बनाता है जिसका नाम "origin" है और यह आपके द्वारा पहले बनाए गए GitHub रिपॉजिटरी की ओर इशारा करता है।
|
|
|
|
1. **स्थानीय फाइलें GitHub पर भेजें**। अब तक आपने स्थानीय रिपो और GitHub रिपो के बीच एक _कनेक्शन_ बनाया है। आइए इन फाइलों को GitHub पर निम्नलिखित कमांड `git push` का उपयोग करके भेजें:
|
|
|
|
> नोट, आपका ब्रांच नाम ```main``` से अलग हो सकता है।
|
|
|
|
```bash
|
|
git push -u origin main
|
|
```
|
|
|
|
यह आपके "main" ब्रांच में आपके कमिट्स को GitHub पर भेजता है।
|
|
|
|
2. **अधिक बदलाव जोड़ें**। यदि आप बदलाव करना जारी रखना चाहते हैं और उन्हें GitHub पर पुश करना चाहते हैं, तो आपको केवल निम्नलिखित तीन कमांड का उपयोग करना होगा:
|
|
|
|
```bash
|
|
git add .
|
|
git commit -m "type your commit message here"
|
|
git push
|
|
```
|
|
|
|
> टिप, आप `.gitignore` फाइल अपनाना चाह सकते हैं ताकि वे फाइलें जिन्हें आप ट्रैक नहीं करना चाहते, GitHub पर दिखाई न दें - जैसे कि वह नोट्स फाइल जिसे आप उसी फ़ोल्डर में स्टोर करते हैं लेकिन उसका सार्वजनिक रिपॉजिटरी में कोई स्थान नहीं है। आप `.gitignore` फाइलों के टेम्पलेट्स [.gitignore templates](https://github.com/github/gitignore) पर पा सकते हैं।
|
|
|
|
#### कमिट संदेश
|
|
|
|
एक शानदार Git कमिट विषय पंक्ति निम्नलिखित वाक्य को पूरा करती है:
|
|
यदि लागू किया गया, तो यह कमिट <आपकी विषय पंक्ति यहां> करेगा।
|
|
|
|
विषय के लिए वर्तमान काल का उपयोग करें: "change" न कि "changed" या "changes"।
|
|
जैसे विषय में, बॉडी (वैकल्पिक) में भी वर्तमान काल का उपयोग करें। बॉडी में बदलाव के लिए प्रेरणा शामिल होनी चाहिए और इसे पिछले व्यवहार के साथ तुलना करनी चाहिए। आप `क्यों` समझा रहे हैं, न कि `कैसे`।
|
|
|
|
✅ GitHub पर कुछ समय बिताएं। क्या आप एक वास्तव में शानदार कमिट संदेश ढूंढ सकते हैं? क्या आप एक बहुत ही न्यूनतम संदेश ढूंढ सकते हैं? आपके विचार में कमिट संदेश में कौन सी जानकारी सबसे महत्वपूर्ण और उपयोगी है?
|
|
|
|
### कार्य: सहयोग करें
|
|
|
|
GitHub पर चीजें डालने का मुख्य कारण अन्य डेवलपर्स के साथ सहयोग करना संभव बनाना था।
|
|
|
|
## दूसरों के साथ प्रोजेक्ट्स पर काम करना
|
|
|
|
> वीडियो देखें
|
|
>
|
|
> [](https://www.youtube.com/watch?v=bFCM-PC3cu8)
|
|
|
|
अपने रिपॉजिटरी में, `Insights > Community` पर जाएं और देखें कि आपका प्रोजेक्ट अनुशंसित सामुदायिक मानकों की तुलना में कैसा है।
|
|
|
|
यहां कुछ चीजें हैं जो आपके GitHub रिपो को बेहतर बना सकती हैं:
|
|
- **विवरण**। क्या आपने अपने प्रोजेक्ट के लिए विवरण जोड़ा है?
|
|
- **README**। क्या आपने README जोड़ा है? GitHub [README](https://docs.github.com/articles/about-readmes/?WT.mc_id=academic-77807-sagibbon) लिखने के लिए मार्गदर्शन प्रदान करता है।
|
|
- **योगदान दिशानिर्देश**। क्या आपके प्रोजेक्ट में [योगदान दिशानिर्देश](https://docs.github.com/articles/setting-guidelines-for-repository-contributors/?WT.mc_id=academic-77807-sagibbon) हैं?
|
|
- **आचार संहिता**। एक [आचार संहिता](https://docs.github.com/articles/adding-a-code-of-conduct-to-your-project/)।
|
|
- **लाइसेंस**। शायद सबसे महत्वपूर्ण, एक [लाइसेंस](https://docs.github.com/articles/adding-a-license-to-a-repository/)।
|
|
|
|
ये सभी संसाधन नए टीम सदस्यों को शामिल करने में मदद करेंगे। और ये आमतौर पर वे चीजें हैं जिन्हें नए योगदानकर्ता आपके कोड को देखने से पहले देखते हैं, यह पता लगाने के लिए कि क्या आपका प्रोजेक्ट उनके समय बिताने के लिए सही जगह है।
|
|
|
|
✅ README फाइलें, हालांकि उन्हें तैयार करने में समय लगता है, अक्सर व्यस्त मेंटेनर्स द्वारा उपेक्षित की जाती हैं। क्या आप किसी विशेष रूप से वर्णनात्मक README का उदाहरण ढूंढ सकते हैं? नोट: कुछ [उपकरण](https://www.makeareadme.com/) हैं जो अच्छे README बनाने में मदद करते हैं जिन्हें आप आज़माना चाह सकते हैं।
|
|
|
|
### कार्य: कुछ कोड मर्ज करें
|
|
|
|
योगदान दस्तावेज़ लोगों को प्रोजेक्ट में योगदान करने में मदद करते हैं। यह बताता है कि आप किस प्रकार के योगदान की तलाश कर रहे हैं और प्रक्रिया कैसे काम करती है। योगदानकर्ताओं को आपके GitHub रिपो में योगदान करने में सक्षम होने के लिए एक श्रृंखला चरणों से गुजरना होगा:
|
|
|
|
1. **आपके रिपो को फोर्क करना**। आप शायद चाहेंगे कि लोग आपके प्रोजेक्ट को _फोर्क_ करें। फोर्क करने का मतलब है कि आपकी रिपॉजिटरी की एक प्रतिकृति उनके GitHub प्रोफ़ाइल पर बनाई जाए।
|
|
1. **क्लोन**। वहां से वे प्रोजेक्ट को अपने स्थानीय मशीन पर क्लोन करेंगे।
|
|
1. **एक ब्रांच बनाएं**। आप चाहेंगे कि वे अपने काम के लिए एक _ब्रांच_ बनाएं।
|
|
1. **अपना बदलाव एक क्षेत्र पर केंद्रित करें**। योगदानकर्ताओं से एक समय में एक चीज़ पर ध्यान केंद्रित करने के लिए कहें - इस तरह उनके काम को _मर्ज_ करने की संभावना अधिक होती है। कल्पना करें कि उन्होंने एक बग फिक्स लिखा, एक नई सुविधा जोड़ी, और कई परीक्षण अपडेट किए - क्या होगा यदि आप 3 में से केवल 2 या 1 को लागू करना चाहते हैं या कर सकते हैं?
|
|
|
|
✅ ऐसी स्थिति की कल्पना करें जहां ब्रांच विशेष रूप से अच्छा कोड लिखने और शिप करने के लिए महत्वपूर्ण हैं। आप किन उपयोग मामलों के बारे में सोच सकते हैं?
|
|
|
|
> नोट, वह बदलाव बनें जिसे आप दुनिया में देखना चाहते हैं, और अपने काम के लिए ब्रांच बनाएं। आपके द्वारा किए गए किसी भी कमिट उस ब्रांच पर किए जाएंगे जिस पर आप वर्तमान में "चेक आउट" हैं। `git status` का उपयोग करें यह देखने के लिए कि वह कौन सी ब्रांच है।
|
|
|
|
आइए एक योगदानकर्ता वर्कफ़्लो पर जाएं। मान लें कि योगदानकर्ता ने पहले ही रिपो को _फोर्क_ और _क्लोन_ कर लिया है ताकि उनके पास एक Git रिपो हो जिस पर वे अपने स्थानीय मशीन पर काम कर सकें:
|
|
|
|
1. **एक ब्रांच बनाएं**। `git branch` कमांड का उपयोग करें ताकि एक ब्रांच बनाई जा सके जिसमें वे बदलाव करेंगे:
|
|
|
|
```bash
|
|
git branch [branch-name]
|
|
```
|
|
|
|
1. **वर्किंग ब्रांच पर स्विच करें**। निर्दिष्ट ब्रांच पर स्विच करें और `git switch` का उपयोग करके वर्किंग डायरेक्टरी को अपडेट करें:
|
|
|
|
```bash
|
|
git switch [branch-name]
|
|
```
|
|
|
|
1. **काम करें**। इस बिंदु पर आप अपने बदलाव जोड़ना चाहते हैं। Git को इसके बारे में बताना न भूलें निम्नलिखित कमांड का उपयोग करके:
|
|
|
|
```bash
|
|
git add .
|
|
git commit -m "my changes"
|
|
```
|
|
|
|
सुनिश्चित करें कि आप अपने कमिट को अच्छा नाम दें, आपके लिए और उस रिपो के मेंटेनर के लिए भी जिसे आप मदद कर रहे हैं।
|
|
|
|
1. **अपने काम को `main` ब्रांच के साथ मिलाएं**। किसी बिंदु पर आप काम पूरा कर लेते हैं और आप अपने काम को `main` ब्रांच के साथ मिलाना चाहते हैं। इस बीच `main` ब्रांच बदल सकती है, इसलिए सुनिश्चित करें कि आप पहले इसे नवीनतम में अपडेट करें निम्नलिखित कमांड का उपयोग करके:
|
|
|
|
```bash
|
|
git switch main
|
|
git pull
|
|
```
|
|
|
|
इस बिंदु पर आप यह सुनिश्चित करना चाहते हैं कि कोई भी _conflicts_, ऐसी स्थिति जहां Git आसानी से _मिलाने_ में असमर्थ हो, आपके वर्किंग ब्रांच में हो। इसलिए निम्नलिखित कमांड चलाएं:
|
|
|
|
```bash
|
|
git switch [branch_name]
|
|
git merge main
|
|
```
|
|
|
|
यह `main` से सभी बदलाव आपके ब्रांच में लाएगा और उम्मीद है कि आप बस जारी रख सकते हैं। यदि नहीं, तो VS Code आपको बताएगा कि Git _कंफ्यूज_ है और आप प्रभावित फाइलों को बदल सकते हैं ताकि यह स्पष्ट हो सके कि कौन सी सामग्री सबसे सटीक है।
|
|
|
|
1. **अपना काम GitHub पर भेजें**। अपना काम GitHub पर भेजने का मतलब दो चीजें हैं। अपने ब्रांच को अपने रिपो पर पुश करना और फिर एक PR, Pull Request खोलना।
|
|
|
|
```bash
|
|
git push --set-upstream origin [branch-name]
|
|
```
|
|
|
|
ऊपर दिया गया कमांड आपके फोर्क किए गए रिपो पर ब्रांच बनाता है।
|
|
|
|
1. **PR खोलें**। अगला, आप एक PR खोलना चाहते हैं। आप ऐसा GitHub पर फोर्क किए गए रिपो पर नेविगेट करके करते हैं। आप GitHub पर एक संकेत देखेंगे जहां यह पूछता है कि क्या आप एक नया PR बनाना चाहते हैं, आप उस पर क्लिक करते हैं और आपको एक इंटरफ़ेस पर ले जाया जाता है जहां आप कमिट संदेश शीर्षक बदल सकते हैं, इसे अधिक उपयुक्त विवरण दे सकते हैं। अब आपने जिस रिपो को फोर्क किया है उसके मेंटेनर इस PR को देखेंगे और _उम्मीद है_ वे इसे सराहेंगे और आपके PR को _मर्ज_ करेंगे। अब आप एक योगदानकर्ता हैं, वाह :)
|
|
|
|
1. **साफ-सफाई करें**। यह अच्छा अभ्यास माना जाता है कि आप सफलतापूर्वक PR मर्ज करने के बाद _साफ-सफाई_ करें। आप अपने स्थानीय ब्रांच और उस ब्रांच को साफ करना चाहते हैं जिसे आपने GitHub पर पुश किया था। पहले इसे स्थानीय रूप से निम्नलिखित कमांड के साथ हटाएं:
|
|
|
|
```bash
|
|
git branch -d [branch-name]
|
|
```
|
|
GitHub पेज पर जाएं और उस रिमोट ब्रांच को हटा दें जिसे आपने अभी-अभी पुश किया है।
|
|
|
|
`Pull request` शब्द थोड़ा अजीब लगता है क्योंकि असल में आप अपनी बदलावों को प्रोजेक्ट में पुश करना चाहते हैं। लेकिन मेंटेनर (प्रोजेक्ट मालिक) या कोर टीम को आपके बदलावों पर विचार करना होता है, इससे पहले कि इसे प्रोजेक्ट की "main" ब्रांच में मर्ज किया जाए। इसलिए आप असल में मेंटेनर से बदलाव का निर्णय मांग रहे हैं।
|
|
|
|
एक pull request वह जगह है जहां आप ब्रांच पर किए गए बदलावों की तुलना और चर्चा कर सकते हैं, जिसमें रिव्यू, टिप्पणियां, इंटीग्रेटेड टेस्ट और अन्य चीजें शामिल होती हैं। एक अच्छा pull request लगभग उन्हीं नियमों का पालन करता है जो एक commit संदेश के लिए होते हैं। आप issue ट्रैकर में किसी issue का संदर्भ जोड़ सकते हैं, जैसे कि जब आपका काम किसी issue को ठीक करता है। इसे `#` के बाद issue नंबर लिखकर किया जाता है। उदाहरण के लिए `#97`।
|
|
|
|
🤞उम्मीद है कि सभी चेक पास हो जाएं और प्रोजेक्ट मालिक आपके बदलावों को प्रोजेक्ट में मर्ज कर दें🤞
|
|
|
|
अपने वर्तमान लोकल वर्किंग ब्रांच को GitHub पर संबंधित रिमोट ब्रांच से सभी नए commits के साथ अपडेट करें:
|
|
|
|
`git pull`
|
|
|
|
## ओपन सोर्स में योगदान कैसे करें
|
|
|
|
पहले, GitHub पर एक ऐसा रिपॉजिटरी (या **repo**) खोजें जो आपके लिए रुचिकर हो और जिसमें आप बदलाव करना चाहते हों। आप इसकी सामग्री को अपनी मशीन पर कॉपी करना चाहेंगे।
|
|
|
|
✅ 'शुरुआती-अनुकूल' रिपॉजिटरी खोजने का एक अच्छा तरीका है [टैग 'good-first-issue' द्वारा खोज करना](https://github.blog/2020-01-22-browse-good-first-issues-to-start-contributing-to-open-source/)।
|
|
|
|
|
|
|
|
कोड कॉपी करने के कई तरीके हैं। एक तरीका है रिपॉजिटरी की सामग्री को "क्लोन" करना, HTTPS, SSH, या GitHub CLI (कमांड लाइन इंटरफेस) का उपयोग करके।
|
|
|
|
अपना टर्मिनल खोलें और रिपॉजिटरी को इस तरह क्लोन करें:
|
|
`git clone https://github.com/ProjectURL`
|
|
|
|
प्रोजेक्ट पर काम करने के लिए, सही फोल्डर पर स्विच करें:
|
|
`cd ProjectURL`
|
|
|
|
आप पूरे प्रोजेक्ट को [Codespaces](https://github.com/features/codespaces), GitHub का एम्बेडेड कोड एडिटर / क्लाउड डेवलपमेंट एनवायरनमेंट, या [GitHub Desktop](https://desktop.github.com/) का उपयोग करके भी खोल सकते हैं।
|
|
|
|
अंत में, आप कोड को ज़िप फोल्डर में डाउनलोड कर सकते हैं।
|
|
|
|
### GitHub के बारे में कुछ और रोचक बातें
|
|
|
|
आप GitHub पर किसी भी सार्वजनिक रिपॉजिटरी को स्टार, वॉच और/या "fork" कर सकते हैं। आप अपने स्टार किए गए रिपॉजिटरी को टॉप-राइट ड्रॉप-डाउन मेनू में पा सकते हैं। यह कोड के लिए बुकमार्किंग जैसा है।
|
|
|
|
प्रोजेक्ट्स में एक issue ट्रैकर होता है, जो ज्यादातर GitHub पर "Issues" टैब में होता है जब तक कि अन्यथा न बताया जाए, जहां लोग प्रोजेक्ट से संबंधित मुद्दों पर चर्चा करते हैं। और Pull Requests टैब वह जगह है जहां लोग प्रगति में बदलावों पर चर्चा और समीक्षा करते हैं।
|
|
|
|
प्रोजेक्ट्स में चर्चा फोरम, मेलिंग लिस्ट, या चैट चैनल जैसे Slack, Discord या IRC में भी हो सकती है।
|
|
|
|
✅ अपने नए GitHub रिपॉजिटरी के चारों ओर देखें और कुछ चीजें आज़माएं, जैसे सेटिंग्स को एडिट करना, अपने रिपॉजिटरी में जानकारी जोड़ना, और एक प्रोजेक्ट बनाना (जैसे Kanban बोर्ड)। आप बहुत कुछ कर सकते हैं!
|
|
|
|
---
|
|
|
|
## 🚀 चुनौती
|
|
|
|
किसी दोस्त के साथ मिलकर एक-दूसरे के कोड पर काम करें। एक प्रोजेक्ट को सहयोगात्मक रूप से बनाएं, कोड को fork करें, ब्रांच बनाएं, और बदलावों को मर्ज करें।
|
|
|
|
## पोस्ट-लेक्चर क्विज़
|
|
[पोस्ट-लेक्चर क्विज़](https://ff-quizzes.netlify.app/web/quiz/4)
|
|
|
|
## समीक्षा और स्व-अध्ययन
|
|
|
|
[ओपन सोर्स सॉफ़्टवेयर में योगदान करने के बारे में अधिक पढ़ें](https://opensource.guide/how-to-contribute/#how-to-submit-a-contribution)।
|
|
|
|
[Git चीटशीट](https://training.github.com/downloads/github-git-cheat-sheet/)।
|
|
|
|
अभ्यास करें, अभ्यास करें, अभ्यास करें। GitHub के पास [skills.github.com](https://skills.github.com) के माध्यम से बेहतरीन लर्निंग पाथ उपलब्ध हैं:
|
|
|
|
- [GitHub पर पहला सप्ताह](https://skills.github.com/#first-week-on-github)
|
|
|
|
आपको अधिक उन्नत पाठ्यक्रम भी मिलेंगे।
|
|
|
|
## असाइनमेंट
|
|
|
|
[GitHub पर पहला सप्ताह का कोर्स](https://skills.github.com/#first-week-on-github) पूरा करें।
|
|
|
|
**अस्वीकरण**:
|
|
यह दस्तावेज़ AI अनुवाद सेवा [Co-op Translator](https://github.com/Azure/co-op-translator) का उपयोग करके अनुवादित किया गया है। जबकि हम सटीकता के लिए प्रयासरत हैं, कृपया ध्यान दें कि स्वचालित अनुवाद में त्रुटियां या अशुद्धियां हो सकती हैं। मूल भाषा में उपलब्ध मूल दस्तावेज़ को आधिकारिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम उत्तरदायी नहीं हैं। |