reset repo

2026-05-13 17:21:50 +00:00 · 2025-01-03 22:30:04 +01:00
commit b166a1d130
314 changed files with 31890 additions and 0 deletions
@@ -0,0 +1,65 @@
+# कमिट में संशोधन करना 
+
+आपके दूरस्थ संग्रहालय में एक परिवर्तन करते हैं, फिर बाद में पता चलता है कि आपके कमिट संदेश में त्रुटि है या आपने अपने सबसे हाल के कमिट में एक पंक्ति जोड़ना भूल दी है।
+आप ऐसा कैसे संपादित करेंगे? इस पर यह ट्यूटोरियल विस्तार से बताता है।
+
+##Github पर अपलोड करने के बाद हाल के कमिट संदेश को संशोधित करना।
+इसे फ़ाइल खोले बिना करने के लिए:
+*     निम्नलिखित कमांड का उपयोग करें ```git commit --amend -m "आपके नए कमिट संदेश के बाद"
+*     चलाना ```git push origin <branch-name>```  संग्रहालय में परिवर्तन को कमिट (commit) करने के लिए क्या होगा।
+
+नोट: यदि आप केवल ```git commit --amend```टाइप करते हैं, तो आपका पाठ संपादित करने के लिए आपके पाठ संपादक खुलेगा। ``-m`` फ़्लैग जोड़ने से इसे रोका जा सकता है।
+
+## एक सिंगल कमिट पर संशोधन करना
+
+तो, यदि हम एक फ़ाइल में एक छोटे से बदलाव को करना भूल जाते हैं, जैसे एक शब्द को बदलना, और हमने पहले से ही उस कमिट को हमारे रिमोट रिपॉजिटरी में पुश कर दिया है?
+
+इसे व्यक्त करने के लिए यहां मेरे कमिट की एक लॉग है:
+```
+g56123f create file bot file
+a2235d updated contributor.md
+a5da0d modified bot file
+```
+चलिए मान लें कि मुझसे एक शब्द बदलने को भूल गया हूँ बॉट फ़ाइल में
+
+इसके लिए दो तरीके हैं। पहला है कि इसमें परिवर्तन को शामिल करने वाला एक नया कमिट हो, जैसे:
+```
+g56123f create file botfile
+a2235d updated contributor.md
+a5da0d modified botfile
+b0ca8f added single word to botfile
+```
+दूसरा तरीका है a5da0d कमिट को संशोधित करना, इस नए शब्द को जोड़ना और इसे एक कमिट के रूप में गिटहब पर पुश करना। दूसरा तरीका बेहतर लगता है क्योंकि यह केवल एक छोटे से बदलाव है।
+
+इसे प्राप्त करने के लिए, हम निम्नलिखित करेंगे:
+
+*   फ़ाइल में संशोधन करें। इस मामले में, मैं बॉट फ़ाइल को संशोधित करके पिछले समय छूट गया शब्द शामिल करूंगा।
+*   आगे बढ़ें, git add <filename> के साथ फ़ाइल को स्टेजिंग क्षेत्र में जोड़ें|
+
+आम तौर पर स्टेजिंग क्षेत्र में फ़ाइलें जोड़ने के बाद, अगला काम होता है git commit -m "हमारा कमिट संदेश" सही?
+लेकिन क्योंकि हम यहां पिछले कमिट को संशोधित करना चाहते हैं, इसलिए हम इसके बजाय निम्नलिखित कमांड चलाएंगे:
+
+*   ```git commit --amend```
+इससे पाठ संपादक खुलेगा और आपको संदेश संपादित करने के लिए कहेगा। आप पिछले जैसा संदेश छोड़ सकते हैं या इसे बदल सकते हैं।
+*   संपादक(Editor) से बाहर निकलें
+*   git push origin <branch-name> के साथ अपने बदलावों को पुश करें
+
+इस तरह, दोनों बदलावों को एक ही सिंगल कमिट में रखा जाएगा।
+
+## रिमोट पर कमिट संशोधित करना
+
+यदि वह कमिट जिसे आप संशोधित करना चाहते हैं पहले से ही रिमोट पर पुश किया गया है, तो इसे संशोधित करने से आपका स्थानीय इतिहास रिमोट से अलग हो जाएगा (क्योंकि आप तदनुसार एक नया कमिट बनाते हैं और संशोधित कमिट को बदल देते हैं)। रिमोट पर कमिट को बदलने के लिए, अपनी शाखा पर रिमोट का इतिहास अधिलेखित करने की आवश्यकता होगी। इसे प्राप्त करने के लिए, ऊपर वर्णित प्रक्रिया का पालन करें, लेकिन जब आप अपनी कमिट को रिमोट पर पुश करें तो फ़ोर्स पुश का उपयोग करें।
+
+
+> **Warning**
+> फ़ोर्स पुश करने से रिमोट परिवर्तन (और उसे छोड़ देने) को अधिलेखित कर देगा और केवल आपके पुश किए गए कमिट रखेगा। रिमोट पर, टीम के अन्य सदस्यों द्वारा उस बीच में किए गए बदलावों को भी अधिलेखित कर देगा।
+
+इस तरह आप रिमोट परिवर्तन को संशोधित करते हैं:
+
+```bash 
+git add <आपकी बदली हुई फ़ाइलें>
+git commit --amend -m "आपका नया कमिट संदेश के बाद"
+git push --force
+```
+
+>उपयोग करने के लिए `--force` के बजाय `--force-with-lease` सुरक्षित विकल्प है जो रिमोट शाखा पर दूसरे लोगों के बदलावों को अधिलेखित करने से बचाता है (यदि ऐसा आपकी इच्छा नहीं है)।
@@ -0,0 +1,128 @@
+# Things a non Programmer can do
+## सुनना शुरू करें
+
+सब कुछ ओपन सोर्स में दूसरे लोगों को शामिल करता है। 
+आप एक टीम में शामिल होने की कोशिश कर रहे हैं, और इसका मतलब है कि आपको समुदाय को समझना होगा और यह कैसे काम करता है।
+एक परियोजना में प्रवेश करके "नमस्ते, यहाँ मुझे लगता है कि इस परियोजना को यह करना चाहिए" कहना आमतौर पर अच्छी बात नहीं मानी जाती है। 
+कुछ परियोजनाएं इस तरह के दृष्टिकोण का स्वागत कर सकती हैं, लेकिन यदि परियोजना काफी समय से चल रही है, तो इस अवधारणा को स्वीकार करने की संभावना कम होती है।
+**परियोजना की आवश्यकताओं को जानने के लिए सुनना सबसे अच्छा तरीका है।**
+
+1. **मेलिंग सूची में शामिल हों**: कई परियोजनाओं के लिए, मेलिंग सूची परियोजना के विकास के बारे में संचार का मुख्य साधन होती है।
+बड़ी परियोजनाओं में, कई मेलिंग सूची उपलब्ध होती हैं।
+उदाहरण के लिए, पोस्टग्रेसक्यूएल परियोजना में कम से कम 12 उपयोगकर्ता-ओरिएंटेड सूचियां और छह डेवलपर सूचियां हैं।
+मैं सुझाव देता हूँ कि आप मुख्य उपयोगकर्ता-ओरिएंटेड सूची और मूल डेवलपर सूची का पालन करें, जिसमें सुनना शुरू करें।
+
+2. **एक ब्लॉग का पालन करें**: मूल डेवलपर द्वारा संचालित ब्लॉग आमतौर पर भविष्य में आने वाले रिलीज के बारे में जानकारी देते हैं,
+और यहां पहुंचने के लिए क्या किया गया है। एक प्लैनेट साइट परियोजना से संबंधित कई स्रोतों से समाचार और ब्लॉग प्रविष्टियों को संग्रहीत करती है।
+यदि कोई प्लैनेट साइट है, जैसे planet.gnome.org या planet.mysql.com, तो वहां से शुरू करें। "प्लैनेट <परियोजनानाम>" के लिए Google में खोजें।
+
+3. **एक IRC चैनल में शामिल हों**: कई ओपन सोर्स परियोजनाओं में विशेष इंटरनेट रिले चैट (IRC) चैनल होते हैं जहां डेवलपर और उपयोगकर्ता समस्याओं और विकास की चर्चा करने के लिए रहते हैं।
+परियोजना की वेबसाइट में देखें कि चैनल का नाम क्या है और यह IRC नेटवर्क कहां मिलेगा।
+
+**टिकट के साथ काम करें**
+कोड किसी भी ओपन सोर्स परियोजना का हृदय होता है, लेकिन सोचें इसे कि कोड लिखना केवल योगदान करने का एकमात्र तरीका नहीं है।
+कोड और कोड के चारों ओर के सिस्टम की रखरखाव को अक्सर नई सुविधाओं को बनाने और बग्स को ठीक करने के दौरान अनदेखा कर दिया जाता है।
+इन क्षेत्रों को एक आसान तरीके से परियोजना में कदम रखने का एक अवसर मानें।
+अधिकांश परियोजनाएं एक सार्वजनिक दृश्यमान ट्रबल टिकट सिस्टम रखती हैं, जिसका लिंक परियोजना की वेबसाइट के मुख पृष्ठ से जुड़ा होता है और दस्तावेज़ीकरण में शामिल होता है।
+यह उपयोगकर्ताओं और डेवलपर्स के बीच संचार का मुख्य माध्यम होता है। इसे अद्यतित रखना परियोजना में मदद करने का एक बड़ा तरीका है।
+आपको टिकटिंग सिस्टम में विशेष अनुमतियाँ प्राप्त करने की आवश्यकता हो सकती है, जो अधिकांश परियोजना नेताओं को आपकी मदद करने की इच्छा बताते ही खुशी से देंगे।
+
+4. **एक बग का निदान करें**: बग्स आमतौर पर गलत रूप में रिपोर्ट किए जाते हैं।
+एक बग का निदान करना और उसे व्याख्या करना, समस्या के विशेषांकों का पता लगाने के काम में डेवलपर्स को समय बचाने में मदद कर सकता है।
+यदि एक उपयोगकर्ता ने "मैं X करते समय सॉफ्टवेयर काम नहीं करता" रिपोर्ट की है, तो कुछ समय निकालें और इस समस्या के कारणों का पता लगाएं।
+क्या यह दोहराया जा सकता है? क्या आप समस्या को बार-बार पैदा करने के लिए कुछ स्टेप्स निर्धारित कर सकते हैं? क्या आप समस्या को सीमित कर सकते हैं, जैसे कि यह केवल एक ब्राउज़र पर होता है लेकिन दूसरे पर नहीं या एक डिस्ट्रो पर होता है लेकिन दूसरे पर नहीं?
+
+यदि आपको पता नहीं है कि समस्या का कारण क्या है, तो संकेतों को सीमित करने में जोखिम लेने का प्रयास करने से किसी दूसरे को इसे सुधारना आसान होता है।
+चाहे आप कुछ भी खोजें, उसे बग सिस्टम में टिकट में जोड़ें ताकि सभी देख सकें।
+
+5. **ठीक हुए बग्स को बंद करें**: अक्सर बग्स को कोडबेस में ठीक कर लिया जाता है, लेकिन उसके बारे में रिपोर्ट किए गए टिकट सिस्टम में अद्यतित नहीं होते हैं।
+इस कचरे को साफ करना समय लेने वाला हो सकता है, लेकिन यह पूरे परियोजने के लिए महत्वपूर्ण है।
+
+एक वर्ष से पुराने टिकटों के लिए टिकट सिस्टम में क्वेरी करें और देखें कि बग अभी भी मौजूद है या नहीं।
+बग ठीक हुआ है और बंद किया जा सकता है यह जानने के लिए परियोजना के रिलीज चेंज लॉग की जांच करें।
+यदि यह ठीक होने के बारे में ज्ञात है, तो टिकट में संस्करण नंबर नोट करें और उसे बंद करें।
+
+नवीनतम संस्करण के साथ बग को पुनः बनाने का प्रयास करें।
+यदि नवीनतम संस्करण के साथ इसे पुनः बनाना संभव नहीं है, तो टिकट में इसे नोट करें और उसे बंद करें।
+यदि यह अभी भी मौजूद है, तो टिकट में यह नोट करें और खुले छोड़ दें।
+
+कोड के साथ काम करना
+प्रोग्रामर्स, सभी अनुभव स्तरों के, परियोजना में कोड के साथ मदद कर सकते हैं।
+सोचें नहीं कि आपको एक कोड जीनियस होना चाहिए ताकि आप अपने पसंदीदा परियोजना में वास्तविक योगदान कर सकें।
+
+यदि आपका काम कोड में संशोधन शामिल है, तो परियोजना द्वारा कोड को योगदानकर्ताओं से प्राप्त करने का तरीका जांचें।
+हर परियोजना की अपनी वर्कफ़्लो होती है, इसलिए कोड सबमिट करने से पहले उसके बारे में पूछें।
+
+उदाहरण के लिए, पोस्टग्रेएसक्यूएल (PostgreSQL) परियोजना इसकी प्रक्रिया में बहुत सख्त है: कोड संशोधन पैच रूप में एक मेलिंग सूची में भेजे जाते हैं जहां मुख्य डेवलपर्स बदलाव के हर पहलू की जांच करते हैं। दूसरी तरफ़, पैरॉट जैसी परियोजना में कोडबेस के लिए संबंधित अधिकार प्राप्त करना आसान होता है। यदि परियोजना GitHub का उपयोग करती है, तो GitHub के पुल अनुरोध सुविधा का उपयोग करने वाली एक वर्कफ़्लो हो सकती है। कोई भी दो परियोजनाएँ एक समान नहीं होतीं।
+
+जब भी आप कोड संशोधित करते हैं, सुनिश्चित करें कि आप समुदाय के एक ज़िम्मेदार सदस्य के रूप में कार्य कर रहे हैं और अपने कोड की शैली को कोडबेस के शेष से मेल खाती हो। आपके द्वारा जोड़ा या संशोधित किया गया कोड शेष के जैसा दिखना चाहिए। शायद आपको ब्रेसिंग स्टाइल या इंडेंटेशन के स्थान परस्पर न पसंद हो, लेकिन एक ऐसा कोड बदलाव सबमिट करना असभ्य है जो मौजूदा मानकों से मेल नहीं खाता है। यह कहने के समान है "मुझे आपकी शैली पसंद नहीं है और मुझे लगता है कि मेरी शैली बेहतर है, इसलिए आपको मेरे तरीके से करना चाहिए।"
+
+6. **बीटा या रिलीज कैंडिडेट (beta or release candidate) का परीक्षण करें**: किसी भी परियोजना जो बहुविधियों पर चलाने के लिए डिज़ाइन की गई हो सकती है, कई प्रकार की पोर्टेबिलिटी समस्याएं हो सकती हैं।
+जब रिलीज के करीब आती है और एक बीटा या रिलीज कैंडिडेट प्रकाशित होता है, तो परियोजना के नेता की आशा होती है कि इसे कई अलग-अलग लोगों और अलग-अलग प्लेटफ़ॉर्मों पर परीक्षण किया जाए।
+आप उन लोगों में से एक हो सकते हैं और सुनिश्चित कर सकते हैं कि पैकेज आपकी प्लेटफ़ॉर्म पर काम करता है।
+
+आमतौर पर आपको केवल सॉफ़्टवेयर को डाउनलोड, बिल्ड और परीक्षण करने की आवश्यकता होती है, लेकिन यदि आप एक असामान्य वितरण या हार्डवेयर पर हैं, तो परियोजना के लिए महत्वपूर्ण मान्यता हो सकती है।
+बस यह रिपोर्ट करें कि बिल्ड और परीक्षण काम करता है, जिससे परियोजना के नेता को पता चलता है कि आगामी रिलीज सुदृढ़ है।
+
+7. **एक बग (bug) को ठीक करें** : यह आमतौर पर उन योगदानकर्ताओं के लिए है जो कोड पर काम करना चाहते हैं।
+यह सरल है: टिकट सिस्टम में एक रोचक लगने वाले बग ढूंढें और कोड में उसे ठीक करने की कोशिश करें।
+अगर यह उचित हो, तो कोड में ठीक करने को दस्तावेज़ीकरण करें।
+यदि कोई परियोजना बग ठीक करने के लिए टेस्टों को शामिल करने की आवश्यकता है, तो एक टेस्ट सुइट में एक टेस्ट जोड़ने का एक अच्छा विचार होता है। आप इस अनजान कोडबेस के चारों ओर छूने के दौरान नोट्स रखें। यदि आप बग को ठीक नहीं कर पाते हैं, तो टिकट में दस्तावेज़ करें कि आपने ठीक करने के प्रयास के हिस्से के रूप में क्या खोजा है। आपके द्वारा मिली जानकारी उनकी मदद करती है जो आपके बाद आते हैं।
+
+8. **एक टेस्ट लिखें:** अधिकांश परियोजनाओं में एक टेस्ट सुइट होती है जो कोड का टेस्ट करती है, लेकिन यह मुश्किल है कि कोई ऐसी टेस्ट सुइट हो जो इसे ज्यादा टेस्ट कर सके।
+C के लिए gcov जैसा एक टेस्ट कवरेज टूल या Perl के लिए Devel::Cover का उपयोग करें ताकि स्रोत कोड में वे क्षेत्र निश्चित हों जो टेस्ट सुइट द्वारा टेस्ट नहीं होते हैं।
+फिर, इसे कवर करने के लिए एक टेस्ट सुइट में एक टेस्ट जोड़ें।
+
+9. **कैंपाइलर चेतावनी (compiler warning) को शांत करें** : बहुत से सी-आधारित परियोजनाओं के बिल्ड प्रक्रिया में अकसर स्क्रीन पर एक अजीब कैंपाइलर चेतावनी दिखाई देती है।
+ये चेतावनियाँ आमतौर पर किसी समस्या के संकेतक नहीं होती हैं, लेकिन ऐसा दिख सकता है।
+बहुत सारी चेतावनियों के होने से कैंपाइलर ऐसा लग सकता है कि यह झूल रहा है।
+देखें कि क्या कोड वास्तव में एक बग को छिपा रह सकता है। यदि नहीं, तो शांत करने के लिए स्रोत को संशोधित करना मददगार होता है ताकि ये गलत चेतावनियाँ छुपा सकें।
+
+10. **टिप्पणी जोड़ें**: कोड में खोज करते समय, आपको कुछ स्थानों पर कंफ़्यूज़ हो सकता है।
+संभावना है कि यदि आप कंफ़्यूज़ हो रहे हैं, तो दूसरे भी होंगे। इन्हें कोड में दस्तावेज़ीकरण करें और एक पैच सबमिट करें।
+
+दस्तावेज़ीकरण के साथ काम करें
+दस्तावेज़ीकरण आमतौर पर एक परियोजना का वह हिस्सा होता है जिसे कम महत्व दिया जाता है।
+यह यह भी संघर्ष कर सकता है क्योंकि इसे उन लोगों की दृष्टि से लिखा गया है जो परियोजना को अच्छी तरह से जानते हैं, बल्कि उनकी नज़रिए से जो इसमें अभी नए हैं।
+यदि आपने कभी एक परियोजना के लिए दस्तावेज़ पढ़ी है जहां आपको लगता है, "ऐसा लगता है मानुअल मांगता है कि मेरे पास पहले से ही पैकेज का उपयोग करने का ज्ञान हो," तो आप जानते हैं कि मैं क्या कह रहा हूँ।
+अक्सर एक ताजगी वाले नज़रों की संचालन में दस्तावेज़ीकरण में कमी का पता लगा सकती है जिसे परियोजना के नजदीकी लोग नहीं देखते हैं।
+
+11. **एक उदाहरण बनाएं**: कोई परियोजना ऐसी नहीं है जिसमें केवल हो-टू उदाहरण हों।
+चाहे यह एक वेब API हो, रूटीन का एक लाइब्रेरी हो, Gimp जैसा एक GUI ऐप हो या कमांड लाइन टूल हो,
+सही उपयोग का एक अच्छा उदाहरण सॉफ़्टवेयर के सही उपयोग को पृष्ठों के दस्तावेज़ीकरण से अधिक स्पष्टता और तेज़ी से समझा सकता है।
+एक API या लाइब्रेरी के लिए, उपकरण का उपयोग करके एक उदाहरण प्रोग्राम बनाएं। यह आपके द्वारा लिखे गए कोड से निकाला जा सकता है, जिसे नियमित करके कम कर दिया जाए।
+टूल के लिए, अपने दैनिक जीवन में इसे कैसे उपयोग किया गया है के वास्तविक उदाहरण दिखाएं। यदि आप दृश्य-ओरिएंटेड हैं,
+ऐप्लिकेशन की स्थापना कैसे करें जैसे महत्वपूर्ण प्रक्रिया का स्क्रीन कैप्चर बनाने का विचार करें।
+समुदाय के साथ काम करें
+ओपन सोर्स केवल कोड के बारे में होता है वही नहीं है। समुदाय ओपन सोर्स को कामयाब बनाता है। यहां वह तरीके हैं जिनसे आप उसे मजबूत कर सकते हैं।
+
+12. **सवाल का जवाब दें**: समुदाय को बनाने की सबसे अच्छी विधि है दूसरों की मदद करना।
+एक सवाल का जवाब देना, विशेष रूप से जब उसे शुरुआती तरीके से अभी अभी समझने वाले व्यक्ति से पूछा जाता है, परियोजना को बढ़ाने और मांगलिक बनाने में महत्वपूर्ण होता है।
+आपका समय जो आप एक शुरुआत करने वाले की मदद करने में लगाते हैं, यद्यपि वे एक सवाल पूछ रहे हों जहां आप आसानी से तेज़ी से "RTFM" लौटा सकते हैं, तो आपको बाद में समुदाय का एक और सक्रिय सदस्य प्राप्त करने में लाभ मिलता है।
+हर कोई कहीं ना कहीं से शुरुआत करता है, और परियोजनाएं जीवंत रहने के लिए निरंतर लोगों के प्रवाह की आवश्यकता होती है।
+
+13. **ब्लॉग पोस्ट लिखें**: यदि आपके पास एक ब्लॉग है, तो उस परियोजना के साथ अपने अनुभवों के बारे में लिखें जिसका आप उपयोग कर रहे हैं।
+सॉफ़्टवेयर का उपयोग करते समय आपने किसी समस्या का सामना किया हो तो उसके समाधान के बारे में बताएं।
+आप दो तरीकों से मदद कर रहे होंगे, एक तो आप उस परियोजना को आपके चारों ओर रखने में मदद कर रहे होंगे,
+और दूसरा, आपकी समस्या को भविष्य में किसी और द्वारा खोजने पर जवाब देने के लिए वेब खोज करने वालों के लिए एक रिकॉर्ड बना रहें होंगे।
+(एक आपके तकनीकी एडवेंचर का ब्लॉग उस सॉफ़्टवेयर के साथ वास्तविक दुनिया के अनुभव को दिखाने का एक उत्कृष्ट तरीका हो सकता है जब आप उसका उपयोग करके नौकरी की तलाश में जाते हैं)|
+
+14. **वेबसाइट में सुधार करें**: यदि आपके पास वेब डिज़ाइन के कौशल हैं और आप सहायता करने के लिए वेबसाइट को और इस प्रकरण में प्रोजेक्ट की जनता के सामने छवि को सुधार सकते हैं, तो यह समय बहुत अच्छा बिताया गया होता है।
+शायद परियोजना को एक ग्राफ़िक बदल चाहिए, या परियोजना को पहचानने के लिए एक लोगो।
+ये सामग्री उन योग्यताओं की कमी हो सकती है जो समुदाय में नहीं हैं। मुझे यह जानकर खुशी होगी कि अगर मेरे परियोजनाओं की वेबसाइटों पर ग्राफ़िक डिज़ाइन मदद मिल सके।
+
+सबसे अधिक महत्वपूर्ण बात यह है कि आप चारों ओर के लोगों के बीच की चर्चा क्या है, इसे सुनें। यदि आप किसी महत्वपूर्ण आवश्यकता को पहचान सकते हैं, तो यह बड़ी बात हो सकती है। उदाहरण के लिए, हाल ही में पैरॉट डेवलपर्स के मेलिंग सूची पर त्रुटि टिकट सिस्टम के रूप में GitHub का उपयोग करने का निर्णय लिया गया, जहां वे पहले वाले Trac स्थापना को छोड़ रहे थे। कुछ लोग इस हरकत के खिलाफ थे क्योंकि उन्हें टिकट को GitHub के सिस्टम में परिवर्तित करने का कोई तरीका नहीं था। एक दिन की बहस के बाद, मैंने उठाने की कोशिश की और कहा "क्या अगर मैं एक कनवर्टर लिखता हूं?" लोग इस विचार से बहुत खुश थे। मैंने 450+ टिकटों के लिए एक कनवर्टर प्रोग्राम लिखने का समय बिताया, इसलिए हमारी टिकट इतिहास में से कोई भी खोने की समस्या नहीं हुई। यह एक बड़ी सफलता थी। मैंने सहयोग किया, और कोर डेवलपर्स पैरॉट पर काम करने के लिए केंद्रित रहे।
+
+
+
+
+
+
+
+
+
+
+
+
+
+
@@ -0,0 +1,45 @@
+# उपयोगी लिंक्स
+
+यह लेख उन सभी युक्तियों और युक्तियों वाली वेबसाइटों, ब्लॉग पोस्टों और सहायक साइटों को समर्पित है जो हमारे जीवन को आसान बनाती हैं। वे हमारी सभी जरूरतों को पूरा करने के लिए एक महान संदर्भ हैं, चाहे वह नौसिखिया हो या विशेषज्ञ। इस पृष्ठ को उन सभी उपयोगी लिंक के सूचकांक के रूप में कार्य करना चाहिए जो ओपन-सोर्स डोमेन में नए लोगों या किसी ऐसे व्यक्ति की मदद करेगा जो अधिक सीखना चाहता है। 
+
+## सूची
+1.  [गिट के लिए इंटरैक्टिव ट्यूटोरियल](https://try.github.io)
+2.  [यूट्यूब: फ़्रीकोडकैंप द्वारा शुरुआती लोगों के लिए Git और GitHub](https://www.youtube.com/watch?v=RGOj5yH7evk)
+3.  [git - सरल मार्गदर्शक](http://rogerdudler.github.io/git-guide/)
+4.  [गिट में कमिट को पूर्ववत करना, ठीक करना या हटाना](http://sethrobertson.github.io/GitFixUm/fixup.html)
+5.  [Git और GitHub ट्यूटोरियल का कई भाषाओं में अनुवाद किया गया](https://github.com/Roshanjossey/first-contributions)
+6.  [संघर्षों को मर्ज करें](https://www.git-tower.com/learn/git/ebook/en/command-line/advanced-topics/merge-conflicts)
+7.  [मर्ज विवादों का समाधान](https://githowto.com/resolving_conflicts)
+8. [Git की मूल बातें - सरल त्वरित प्रारंभ मार्गदर्शिका](https://blog.praveen.science/basics-of-git-the-quick-start-guide/)
+9. [Spotify एजाइल मेथडोलॉजी के हमारे तरीके में Git मानकों का पालन किया गया](https://blog.praveen.science/git-standards-followed-in-our-way-of-spotify-agile-methodolgy/)
+10. [गिट शॉर्टकट](https://blog.praveen.science/git-shortcuts/)
+11.  [कई भाषाओं में आधिकारिक Git चीट शीट](https://services.github.com/on-demand/resources/cheatsheets)
+12.  [टॉवर से गिट चीट शीट](https://www.git-tower.com/learn/cheat-sheets/git)
+13.  [सामान्य गिट समस्याएँ](https://www.codementor.io/citizen428/git-tutorial-10-common-git-problems-and-how-to-fix-them-aajv0katd)
+14. [Git रिबेस](https://blog.gitprime.com/git-rebase-an-illustrated-guide/)
+15. [रीबेस और स्क्वैष करना सीखें](https://github.com/servo/servo/wiki/Beginner%27s-guide-to-rebasing-and-squashing)
+16. [Git चीटशीट जो कमांड और फ़ाइलों के बीच संबंध दिखाती है](http://ndpsoftware.com/git-cheatsheet.html)
+17. [कैसे योगदान करें](https://opensource.guide/how-to-contribute/)
+18. [ओपन सोर्स के साथ शुरुआत करें](https://github.com/OpenSourceHelpCommunity/Getting-Started-With-Contributing-to-Open-Sources)
+19. [कैसे योगदान करें](https://github.com/freeCodeCamp/how-to-contribute-to-open-source)
+20. [एटलसियंस गिट ट्यूटोरियल](https://www.atlassian.com/git)
+21. [पुल अनुरोध समीक्षा](https://help.github.com/articles/about-pull-request-reviews/)
+22. [गिट के लिए एक और इंटरैक्टिव ट्यूटोरियल](https://learngitbranching.js.org/)
+23. [गिट कमांडलाइन चीट-शीट](https://gist.github.com/davfre/8313299)
+24. [प्रोग्रामिंग के लिए पुस्तकें](https://github.com/EbookFoundation/free-programming-books)
+25. [पेशेवर युक्तियों और रहस्यों की ई-पुस्तक](https://goalkicker.com/GitBook/GitProfessionalTipsSecrets.pdf)
+26. [गिट पेशेवर बनने के सरल नियमों के बारे में ट्यूटोरियल](https://medium.freecodecamp.org/follow-these-simple-rules-and-youll-become-a-git-and-github-master-e1045057468f)
+27. [Git कम्मिट संदेशों के बारे में एक नोट](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html)
+28. [बेहतर कम्मिट संदेश के लिए 5 उपयोगी युक्तियाँ](https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message)
+29. [Git का उपयोग करके वरज़न कंट्रोल](https://ourcodingclub.github.io/2017/02/27/git.html)
+30. [Git के साथ वरज़न कंट्रोल](https://www.udacity.com/course/version-control-with-git--ud123)
+31. [Google से कौरसेरा पाठ्यक्रम का ऑडिट करें](https://www.coursera.org/learn/introduction-git-github)
+32. [वीएस कोड में वरज़न कंट्रोल का उपयोग करना](https://code.visualstudio.com/docs/editor/versioncontrol)
+33. [Git बनाम Github: क्या अंतर है और दोनों के साथ कैसे शुरुआत करें](https://kinsta.com/knowledgebase/git-vs-github/)
+34. [हेलो वर्ल्ड GitHub गाइड](https://guides.github.com/activities/hello-world/)
+35. [GitHub का उपयोग कैसे करें](https://www.edureka.co/blog/how-to-use-github/)
+36. [Git और Github के 10 दिन](https://github.com/Asabeneh/10-days-of-git-and-github)
+37. [GitHub के लिए कीबोर्ड शॉर्टकट](https://docs.github.com/en/get-started/using-github/keyboard-shortcuts)
+38. [संपूर्ण Git और GitHub ट्यूटोरियल कुणाल कुशवाह द्वारा](https://www.youtube.com/watch?v=apGV9Kg7ics&ab_channel=KunalKushwaha)
+39. [गिट वर्कफ़्लो चीट शीट](https://drive.google.com/uc?export=download&id=1QPRh5YmqQm4DFfitelPYlBTWC2I6tTTM)
+और अधिक लिंक जोड़ते रहें, जो आपको उपयोगी लगें।
@@ -0,0 +1,31 @@
+## एक नई फ़ाइल जोड़ने का ट्यूटोरियल
+
+यदि आप एक नई फ़ाइल को अपने Git रिपॉज़िटरी में जोड़ना चाहते हैं, तो यह ट्यूटोरियल आपकी मदद करेगा।
+
+1. **नई फ़ाइल बनाएं**:
+   - अपने प्रोजेक्ट फ़ोल्डर में जाएं।
+   - नई फ़ाइल बनाने के लिए अपने पसंदीदा टेक्स्ट संपादक का उपयोग करें या आपका कोई IDE हो तो वहां से नई फ़ाइल बना सकते हैं।
+   - फ़ाइल को विशेष नाम दें और सहेजें।
+
+2. **फ़ाइल को स्टेज करें**:
+   - टर्मिनल खोलें और रिपॉज़िटरी फ़ोल्डर में जाएं।
+   - नई फ़ाइल को स्टेज करने के लिए निम्नलिखित कमांड का उपयोग करें:
+     ```
+     git add नया_फ़ाइल.एक्शन
+     ```
+
+3. **कमिट करें**:
+   - फ़ाइल को स्टेज करने के बाद, एक कमिट बनाएं।
+   - निम्नलिखित कमांड का उपयोग करें:
+     ```
+     git commit -m "नई फ़ाइल जोड़ी गई"
+     ```
+
+4. **रिमोट रिपॉज़िटरी में पुश करें**:
+   - आपकी फ़ाइल अब आपके लोकल रिपॉज़िटरी में है। अब इसे रिमोट रिपॉज़िटरी में भेजने के लिए निम्नलिखित कमांड का उपयोग करें:
+     ```
+     git push दूरस्थ_शाखा
+     ```
+   - यहाँ "दूरस्थ_शाखा" वह नाम है जिसमें आप फ़ाइल जोड़ना चाहते हैं।
+
+अब आपने एक नई फ़ाइल अपने रिपॉज़िटरी में जोड़ दी है।
@@ -0,0 +1,23 @@
+# एक कमिट शाखा को एक अलग शाखा में ले जाना
+क्या होगा यदि आप कोई बदलाव कमिट करते हैं, और फिर महसूस करें कि आप एक अलग शाखा में हैं?
+आप इसे कैसे बदल सकते हैं? यह ट्यूटोरियल कवर करता है।
+
+## सबसे मौजूदा काम को मौजूदा शाखा में ले जाना
+इस काम को करने के लिए, निम्नलिखित कदमों का पालन करें:
+
+``` git reset HEAD~ --soft ``` - आपकी आखिरी कमिट को पूर्ववत करेगा, लेकिन उपलब्ध परिवर्तनों को छोड़ देगा।
+``` git stash ``` - आपके निर्देशिका की स्थिति को बचाएगा।
+``` git checkout name-of-the-correct-branch ``` - दूसरी शाखा में स्विच करेगा।
+``` git stash pop ``` - आखिरी स्टेशेड स्टेटस को हटा देगा।
+``` git add ``` - या अलग-अलग फाइलों को एक साथ स्टेज करने का प्रयास करेगा।
+``` git commit -m "आपका संदेश यहां" ``` - परिवर्तनों को सुरक्षित करेगा और कमिट करेगा।
+
+अब आपके परिवर्तन सही शाखा पर हैं
+
+### सबसे पुराना काम एक नई शाखा में ले जाना
+इस काम को करने के लिए, निम्नलिखित कदमों का पालन करें:
+``` git branch newbranch``` - एक नई शाखा बनाएगा। सभी कमिट को सुरक्षित कर देगा।
+``` git reset --hard HEAD~#``` - मास्टर को वापस # कमिट में ले जाएगा। याद रखें, यह काम मास्टर से जा चुका होगा।
+``` git checkout newbranch``` - आपके द्वारा बनाई गई शाखा में जाएगा। इसमें सभी कमिट होंगे।
+
+याद रखें: कोई भी बदलाव कमिट नहीं किया गया होगा तो वह खो जाएगा।
@@ -0,0 +1,22 @@
+Here's the corrected README.md file with improved grammar:
+
+# गिट से एक फाइल को हटाना
+कभी-कभी, आपको किसी फ़ाइल को Git से हटाने की आवश्यकता होती है, लेकिन आप नहीं चाहते कि यह आपके कंप्यूटर से हटा दिया जाए। आप निम्नलिखित कमांड का उपयोग करके इसे प्राप्त कर सकते हैं:
+
+``git rm <file> --cached``
+
+## इसका क्या मतलब है?
+Git अब हटाई गई फ़ाइल में किए गए परिवर्तनों का ट्रैकिंग नहीं करेगा। जैसा कि Git को पता होगा, आपने इस फ़ाइल को हटा दिया है। यदि आपने अपने फ़ाइल सिस्टम में फ़ाइल का पता लगाने का प्रयास किया हो, तो आप देखेंगे कि यह अभी भी वहीं है।
+
+यह ध्यान दें कि ऊपर के उदाहरण में, ``--cached`` फ़्लैग का प्रयोग किया गया है। अगर हमने इस ध्वज को नहीं जोड़ा होता, तो Git न केवल रेपोसिटरी से, बल्कि आपके फ़ाइल सिस्टम से भी फ़ाइल को हटा देता।
+
+यदि आप ``git commit -m "Remove file1.js"`` के साथ इस परिवर्तन को करते हैं और फिर ``git push origin master`` का उपयोग करके दूरस्थ रेपोसिटरी में पुश करते हैं, तो दूरस्थ रेपोसिटरी में फ़ाइल को हटा दिया जाएगा।
+
+## अतिरिक्त विशेषताएँ
+- यदि आपको एक से अधिक फ़ाइलों को हटाना है, तो आप उन सभी को एक ही कमांड में शामिल कर सकते हैं:
+
+``git rm file1.js file2.js file3.js --cached``
+
+- आप वाइल्डकार्ड (*) का उपयोग करके समान प्रकार की फ़ाइलों को हटाने के लिए उपयोग कर सकते हैं। उदाहरण के लिए, यदि आप अपने स्थानीय भंडार से सभी .txt फ़ाइलों को हटाना चाहते हैं:
+
+``git rm *.txt --cached``
@@ -0,0 +1,31 @@
+# अपने रिपॉजिटरी से एक शाखा निकालें
+
+यदि आपने अब तक ट्यूटोरियल का पालन किया है, तो हमारी `<add-your-name>` शाखा ने अपना उद्देश्य पूरा कर लिया है, अब यह आपके स्थानीय मशीन के रेपो से इसे हटाने का समय है। यह आवश्यक नहीं है, लेकिन इस शाखा का नाम इसके बजाय विशेष उद्देश्य दिखाता है। इसका जीवन संगत रूप से छोटा हो सकता है।
+
+सबसे पहले, अपने मास्टर में अपने `<add-your-name>` को मर्ज करें, इसलिए अपनी मास्टर शाखा पर जाएं:
+```
+git checkout master
+```
+
+उसके बाद मास्टर में `<add-your-name>`मर्ज करें:
+```
+git merge <add-your-name> master
+```
+
+फिर अपने स्थानीय मशीन के रेपो से `<add-your-name>` निकालें:
+```
+git branch -d <add-your-name>
+```
+
+अब आपने अपनी स्थानीय मशीन की `<add-your-name>` शाखा हटा दी है और सब कुछ साफ़ सुथरा लग रहा है।
+हालांकि, इस समय, आपके पास अभी भी आपके गिटहब फोर्क में `<add-your-name>` शाखा होनी चाहिए। हालांकि, इससे पहले कि आप इसे हटा दें, याद रखें कि आपने इस रिमोट शाखा से अपने रेपो को "पुल रिक्वेस्ट" भेजा है। इसलिए जब तक कि मैं इसे मर्ज नहीं करता हूं, इस शाखा को न हटाएं।
+
+हालांकि, अगर मैंने आपकी शाखा मर्ज कर ली है और आप रिमोट शाखा को हटाना चाहते हैं, तो इसका उपयोग करें:
+```
+git push origin --delete <add-your-name>
+```
+
+अब, आप जानते हैं कि अपनी शाखाओं को कैसे साफ किया जाए।
+समय के साथ, मेरे सार्वजनिक रिपो में कई रेपो जोड़े जाएंगे। और आपकी स्थानीय मशीन और आपके गिटहब फर्क की मास्टर शाखाएं अद्यतित नहीं होंगी। तो अपने रेपोसिटोरिएस को मेरे साथ सिंक्रनाइज़ करने के लिए, नीचे दिए गए चरणों का पालन करें।
+
+#### [अपने फोर्क को रिपॉजिटरी के साथ सिंक रखना] (keeping-your-fork-synced-with-this-repository.md)
@@ -0,0 +1,18 @@
+# एक शाखा रीसेट करें
+
+```reset``` वह कमांड है जिसका उपयोग तब किया जा सकता है जब हम किसी कमिट या शाखा के संबंध में रिपॉजिटरी को रीसेट करना चाहते हैं। एक रीसेट, जैसा कि नाम से पता चलता है, वर्तमान शाखा पर सब कुछ त्याग देता है और इसे उस शाखा के समान बना देता है जिसके साथ हमने आधार शाखा को रीसेट करना चुना (इसे मूल शाखा भी कहा जाता है)। इसका अनिवार्य रूप से मतलब यह है कि हमारे पास मूल शाखा के नाम के साथ मूल शाखा की एक कॉपी होगी।<br/>
+हालाँकि, सवाल यह है कि हम आधार शाखा को क्यों नहीं हटा देते हैं और मूल शाखा से आधार शाखा के नाम से एक नई शाखा क्यों नहीं चेकआउट कर देते हैं। तकनीकी रूप से, इसका प्रभाव रीसेट करने जैसा ही होगा लेकिन कुछ औद्योगिक स्थितियों में हमारे पास किसी शाखा को हटाने की पहुंच नहीं है, या हम किसी शाखा को हटा नहीं सकते हैं क्योंकि यह सीआई/सीडी पाइपलाइन या शायद चल रहे वर्कफ़्लो को बाधित/बाधित कर देगा। इसलिए, ऐसी स्थितियों से बचने के लिए जो डाउनटाइम का कारण बन सकती हैं, हम सुझाव देते हैं कि जब भी हम किसी विशेष शाखा को रीसेट करना चाहते हैं तो `git reset` का उपयोग करें।
+
+## कम्मांड
+
+शाखा के लिए गिट रीसेट निष्पादित करना बहुत आसान है।
+```
+git reset <base_branch> <origin_branch>
+```
+
+उदाहरण के तौर पर:
+```
+git reset stage master --hard
+```
+उपरोक्त कमांड `stage` शाखा को `master` के साथ रीसेट कर देगा और इसलिए `stage` को बिल्कुल `master` के समान बना देगा।
+आप सोच रहे होंगे कि `--hard` फ्लैग का उपयोग क्यों किया जाता है? इसका उद्देश्य उन सभी परिवर्तनों को अनदेखा करना है जो रीसेट से पहले/बाद में होंगे या होंगे।
@@ -0,0 +1,19 @@
+# कमिट रीसेट करें
+
+
+```reset``` वह कमांड है जिसका उपयोग तब किया जा सकता है जब हम रिपॉजिटरी को पिछली कमिट में वापस ले जाना चाहते हैं, उस कमिट के बाद किए गए किसी भी बदलाव को छोड़कर।<br/>
+किसी कमिट को रीसेट करने और वापस लाने के बीच मुख्य अंतर यह है कि git रीसेट ```फ़ाइल को अनस्टेज करता है और हमारे परिवर्तनों को कार्यशील निर्देशिका में वापस लाता है``` और git revert ```रिमोट रिपॉजिटरी से कमिट्स को हटा देता है```। <br/>
+
+```git reset``` निम्नलिखित कमांड का उपयोग करके प्राप्त किया जा सकता है:
+- निम्नलिखित कमांड निम्नलिखित दो मापदंडों का उपयोग करके सभी कमिटों का सारांश देगा:
+   
+      - कमिट हैश के पहले सात अक्षर - यही वह है जिसे हमें अपने **reset** कमांड में संदर्भित करना होगा।
+      - प्रतिबद्ध संदेश
+  
+    ```
+    git log --oneline
+    ```
+
+- कोई निम्नलिखित कमांड का उपयोग करके रिपॉजिटरी को विशिष्ट कमिट पर वापस रीसेट कर सकता है: <br />
+  ```गिट रीसेट कमिटहैश```
+  जहां कमिटहैश कमिट हैश के पहले 7 अक्षर हैं जो हमें लॉग में मिले|