GitHub प्रवाह के घटक

पूरा किया

इस इकाई में, हम GitHub प्रवाह के निम्नलिखित घटकों की समीक्षा कर रहे हैं:

• शाखाएँ
• करता
• पुल अनुरोध
• गिटहब फ्लो
• गिट प्रवाह

GitHub प्रवाह के घटक

इससे पहले कि हम GitHub-विशिष्ट वर्कफ़्लोज़ में उतरें, यह समझना उपयोगी है कि GitHub Flow सीधे Git की मूलभूत अवधारणाओं पर बनाता है।

गिट समय के साथ आपके कोड में परिवर्तनों को ट्रैक और प्रबंधित करने के लिए उपकरण प्रदान करता है। GitHub सहयोग के लिए शाखाओं, प्रतिबद्धताओं, पुल अनुरोधों और दृश्य इंटरफेस जैसी सुविधाओं के साथ उन उपकरणों का उपयोग करना आसान बनाकर इस पर बनाता है। आइए यह देखकर शुरू करें कि ये अवधारणाएं GitHub में कैसे काम करती हैं।

शाखाएं क्या हैं

पिछले सेक्शन में, हमने आपके रिपॉजिटरी में एक नई फाइल और एक नई ब्रांच बनाई है।

शाखाएँ GitHub अनुभव का एक अनिवार्य हिस्सा हैं। वे आपको डिफ़ॉल्ट शाखा को प्रभावित किए बिना परिवर्तन करने देते हैं।

आपकी शाखा नई सुविधाओं या सुधारों के साथ प्रयोग करने के लिए एक सुरक्षित स्थान है। अगर आप कोई गलती करते हैं, तो आप अपने बदलाव वापस ला सकते हैं या गलती ठीक करने के लिए और बदलाव पुश कर सकते हैं. आपके परिवर्तन डिफ़ॉल्ट शाखा पर तब तक अपडेट नहीं होंगे जब तक आप अपनी शाखा को मर्ज नहीं करते।

नोट

वैकल्पिक रूप से, आप एक नई शाखा बना सकते हैं और टर्मिनल में गिट का उपयोग करके इसे देख सकते हैं। आदेश git checkout -b newBranchName

कमिट क्या हैं

पिछली इकाई में, आपने कमिट को धक्का देकर रिपॉजिटरी में एक नई फ़ाइल जोड़ी। आइए संक्षेप में समीक्षा करें कि कमिट क्या हैं।

एक प्रतिबद्ध एक शाखा पर एक या अधिक फाइलों में परिवर्तन है। प्रत्येक प्रतिबद्धता को एक अद्वितीय आईडी, टाइमस्टैम्प और योगदानकर्ता द्वारा ट्रैक किया जाता है, भले ही वह कमांड लाइन के माध्यम से या सीधे गिटहब के वेब इंटरफेस में बनाया गया हो। कमिट किसी फ़ाइल या लिंक किए गए आइटम के इतिहास की समीक्षा करने वाले किसी भी व्यक्ति के लिए एक स्पष्ट ऑडिट ट्रेल प्रदान करते हैं, जैसे कि कोई समस्या या पुल अनुरोध।

आप अपने टर्मिनल में Git का उपयोग करके एक कमिट बना सकते हैं:

git commit -m "Add a helpful commit message"

गिट रिपॉजिटरी के भीतर, एक फ़ाइल कई वैध राज्यों में मौजूद हो सकती है क्योंकि यह संस्करण नियंत्रण प्रक्रिया से गुजरती है। गिट रिपॉजिटरी में फ़ाइल के लिए प्राथमिक अवस्थाएँ अनट्रैक्ड और ट्रैक किए गए हैं।

अनट्रैक: फ़ाइल की प्रारंभिक स्थिति जब यह अभी तक गिट रिपॉजिटरी का हिस्सा नहीं है। गिट अपने अस्तित्व से अनजान है।

ट्रैक किया गया: एक ट्रैक की गई फ़ाइल वह है जिसे गिट सक्रिय रूप से मॉनिटर कर रहा है। यह निम्नलिखित उपराज्यों में से एक में हो सकता है:

• असंशोधित: फ़ाइल ट्रैक की गई है, लेकिन पिछली commit के बाद से इसे संशोधित नहीं किया गया है।
• संशोधित: फ़ाइल को अंतिम commit के बाद से बदल दिया गया है, लेकिन ये परिवर्तन अभी तक अगले commit के लिए स्टेज नहीं किए गए हैं।
• स्टेज्ड: फ़ाइल को संशोधित किया गया है, और परिवर्तनों को स्टेजिंग क्षेत्र (जिसे इंडेक्स भी कहा जाता है) में जोड़ा गया है। ये परिवर्तन किए जाने के लिए तैयार हैं।
• प्रतिबद्ध: फ़ाइल रिपॉजिटरी के डेटाबेस में है। यह फ़ाइल के नवीनतम प्रतिबद्ध संस्करण का प्रतिनिधित्व करता है।

ये स्थितियाँ आपकी टीम को प्रत्येक फ़ाइल की स्थिति और संस्करण नियंत्रण प्रक्रिया में यह समझने में मदद करती हैं।

पुल अनुरोध क्या हैं?

एक पुल अनुरोध वह तंत्र है जिसका उपयोग यह संकेत देने के लिए किया जाता है कि एक शाखा से कमिट दूसरी शाखा में विलय करने के लिए तैयार हैं।

पुल अनुरोध सबमिट करने वाला टीम सदस्य एक या अधिक समीक्षकों से कोड सत्यापित करने और मर्ज को अनुमोदित करने के लिए कहता है. इन समीक्षकों के पास परिवर्तनों पर टिप्पणी करने, अपना स्वयं का जोड़ने, या आगे की चर्चा के लिए पुल अनुरोध का उपयोग करने का अवसर है।

GitHub ड्राफ्ट पुल अनुरोधों का भी समर्थन करता है, जो आपको एक पुल अनुरोध खोलने देता है जो अभी तक समीक्षा के लिए तैयार नहीं है।

एक बार परिवर्तन स्वीकृत हो जाने के बाद (यदि आवश्यक हो), पुल अनुरोध की स्रोत शाखा (तुलना शाखा) को आधार शाखा में मिला दिया जाता है।

अब जब आपने देखा है कि शाखाएं, प्रतिबद्ध और पुल अनुरोध कैसे काम करते हैं, तो आइए देखें कि वे GitHub Flow में एक साथ कैसे आते हैं।

GitHub प्रवाह

GitHub प्रवाह एक सरल वर्कफ़्लो है जो आपको सुरक्षित रूप से परिवर्तन करने और साझा करने में मदद करता है। विचारों को आज़माने और शाखाओं, पुल अनुरोधों और विलय का उपयोग करके अपनी टीम के साथ सहयोग करने के लिए यह बहुत अच्छा है।

नोट

GitHub प्रवाह कई लोकप्रिय वर्कफ़्लोज़ में से एक है। अन्य में गिट प्रवाह और ट्रंक-आधारित विकास शामिल हैं।

अब जब हम GitHub की मूल बातें जानते हैं तो हम GitHub प्रवाह और इसके घटकों के माध्यम से चल सकते हैं।

1. एक शाखा बनाकर प्रारंभ करें ताकि आपके परिवर्तन, सुविधाएँ या सुधार मुख्य शाखा को प्रभावित न करें।
2. इसके बाद, शाखा में अपने अपडेट करें। यदि आपका वर्कफ़्लो इसका समर्थन करता है, तो आप मर्ज करने से पहले उनका परीक्षण करने के लिए इस शाखा से परिवर्तनों को परिनियोजित कर सकते हैं।
3. अब, प्रतिक्रिया आमंत्रित करने और समीक्षा शुरू करने के लिए एक पुल अनुरोध खोलें।
4. फिर, टिप्पणियों की समीक्षा करें और अपनी टीम की प्रतिक्रिया के आधार पर कोई भी आवश्यक अपडेट करें।
5. अंत में, एक बार जब आप अपने परिवर्तनों में आश्वस्त हो जाते हैं, तो अनुमोदन प्राप्त करें और पुल अनुरोध को मुख्य शाखा में मर्ज करें।
6. उसके बाद, अपने भंडार को साफ रखने के लिए शाखा को हटा दें और पुरानी शाखाओं का उपयोग करने से बचें।

गिट प्रवाह

जबकि GitHub Flow निरंतर वितरण के लिए डिज़ाइन किया गया एक हल्का वर्कफ़्लो है, Git प्रवाह एक अधिक संरचित ब्रांचिंग मॉडल है जिसका उपयोग अक्सर रिलीज़-संचालित वातावरण में किया जाता है। Git Flow GitHub Flow से अधिक लंबा रहा है, और आप अभी भी डिफ़ॉल्ट शाखा के बजाय master उपयोग किए गए शब्द main को देख सकते हैं।

विन्सेंट ड्रेसेन द्वारा छवि, 'एक सफल गिट ब्रांचिंग मॉडल' से

गिट प्रवाह शाखा प्रकार

गिट प्रवाह कई लंबे समय तक रहने वाली और अस्थायी शाखाओं का उपयोग करता है:

• मास्टर: हमेशा उत्पादन-तैयार कोड को दर्शाता है।
• develop: इसमें अगली रिलीज़ के लिए नवीनतम डेवलपमेंट कार्य शामिल है.
• सुविधा/*: नई सुविधाएँ बनाने के लिए उपयोग किया जाता है; से develop शाखित और पूरा होने पर वापस विलय कर दिया।
• *: से developएक नया उत्पादन रिलीज तैयार करता है; अंतिम परीक्षण और मामूली बग फिक्स की अनुमति देता है।
• *: उत्पादन समस्याओं को जल्दी से पैच करने के लिए उपयोग किया जाता है; से masterशाखित ।

गिट प्रवाह प्रक्रिया कैसे काम करती है

1. डेवलपर्स नई कार्यक्षमता बनाने के लिए develop बनाते हैं।
2. जब रिलीज़ का समय होता है, तो रिलीज़ शाखा से developबनाई जाती है. यह रिलीज तैयारी के काम को अलग करता है ताकि विकास निर्बाध रूप से जारी रह सके।
3. बग फिक्स को रिलीज शाखा में जोड़ा जा सकता है, लेकिन प्रमुख सुविधाओं को भविष्य के रिलीज के लिए इंतजार करना चाहिए।
4. एक बार तैयार होने के बाद, रिलीज़ शाखा को एक संस्करण संख्या में master विलय कर दिया जाता है और टैग किया जाता है। GitHub इन टैग का उपयोग आपको रिलीज़ नोट्स बनाने में मदद करने के लिए कर सकता है।
5. उसी रिलीज़ शाखा को सिंक में रखने के लिए वापस develop मर्ज किया जाना चाहिए।
6. यदि कोई महत्वपूर्ण उत्पादन बग उत्पन्न होती है, तो एक हॉटफिक्स शाखा से masterबनाया जाता है। एक बार तय हो जाने के बाद, यह दोनों master में विलय हो जाता है और develop.

गिट प्रवाह का उपयोग कब करें

• शेड्यूल किए गए या वर्शन किए गए रिलीज़ वाले प्रोजेक्ट के लिए सर्वश्रेष्ठ रूप से उपयुक्त
• यदि आप कई उत्पादन संस्करणों (जैसे, दीर्घकालिक समर्थन शाखाओं) को बनाए रखते हैं तो सहायक
• धीमी, अधिक संरचित विकास चक्रों (जैसे, उद्यम या विनियमित वातावरण) के लिए आदर्श
• अतिरिक्त शाखा प्रबंधन के कारण GitHub Flow की तुलना में अधिक "हैवीवेट" माना जाता है

नोट

गिट प्रवाह शाखाओं को एकीकृत करने के लिए मर्ज कमिट मानता है। रीबेस या स्क्वैश मर्ज का उपयोग करना इसकी शाखा संरचना और इतिहास ट्रैकिंग में हस्तक्षेप कर सकता है।

GitHub का उपयोग करने वाली कई टीमों के लिए, GitHub Flow सरल और तेज़ है। लेकिन अगर आपकी टीम पूर्वानुमेयता को महत्व देती है और अधिक रिलीज योजना की आवश्यकता है, तो गिट प्रवाह बेहतर फिट हो सकता है।

Congratulations! आप अभी-अभी पूर्ण GitHub Flow से गुजरे हैं - और पता लगाया है कि Git प्रवाह रिलीज-संचालित परियोजनाओं के लिए एक संरचित विकल्प कैसे प्रदान करता है।

आइए अगले भाग पर चलते हैं जहां हम मुद्दों और चर्चाओं के बीच के अंतर को कवर करेंगे।