भ्रम के बिना टीम वर्क: गिट में ब्रांचिंग रणनीतियों को समझना

परिचय

सॉफ्टवेयर विकास में संस्करण नियंत्रण प्रणाली के लिए गिट वास्तविक उद्योग मानक बन गया है। आपको पहले मेरा लेख पढ़ना चाहिए कि गिट क्या है और कैसे शुरू करें। क्या आपने इसे पढ़ा है? बहुत बढ़िया, चलो चलें! यह पसंद है या नहीं, लिनुस टोवाल्ड्स द्वारा बनाया गया यह टूल रिटायर होने वाला नहीं है। इसलिए, इस बारे में बात करना समझ में आता है कि वितरित टीमें गिट के साथ कैसे काम करती हैं और इसके लिए उन्हें कौन सी ब्रांचिंग रणनीति चुननी चाहिए। यह कोई महत्वहीन प्रश्न नहीं है। एक नई विकास टीम को इकट्ठा करते समय जिसने पहले एक साथ काम नहीं किया है, शाखाओं की रणनीति अक्सर तय करने वाली पहली चीजों में से एक होती है। और कुछ लोग यह साबित करने के लिए मुंह से झाग निकाल रहे होंगे कि एक रणनीति दूसरी से बेहतर है। इसलिए, मैं आपको उनके बारे में कुछ सामान्य जानकारी देना चाहता हूं।

क्या ब्रांचिंग रणनीतियाँ आवश्यक हैं?

वे वाकई जरूरी हैं। बहुत ज़रूरी। क्योंकि अगर टीम किसी बात पर सहमत नहीं होती है, तो टीम का प्रत्येक सदस्य वही करेगा जो वह चाहता है:

• किसी भी ब्रांच में काम कर रहे हैं
• मनमानी अन्य शाखाओं में विलय
• कुछ शाखाओं को हटाना
• नए बना रहे हैं
• और इसलिए टीम का प्रत्येक सदस्य एक अप्रबंधित प्रवाह में कार्य करेगा।

इसलिए हमारे पास नीचे विचार करने के लिए तीन रणनीतियाँ हैं। चल दर!

गिटहब प्रवाह

यह ब्रांचिंग रणनीति, विचित्र रूप से पर्याप्त है, GitHub पर पसंद की जाती है :) यह नियमों के एक सेट के साथ आती है :

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

गिटहब फ्लो के अनुसार, इससे पहले कि आप कुछ नया काम करना शुरू करें, चाहे वह फिक्स हो या कोई नया फीचर, आपको मास्टर के आधार पर एक नई शाखा बनाने और उसे एक उपयुक्त नाम देने की आवश्यकता है। अगला, कार्यान्वयन पर काम शुरू होता है। आपको लगातार एक ही नाम से रिमोट सर्वर पर सबमिट करना चाहिए। जब आप निष्कर्ष निकालते हैं कि सब कुछ तैयार है, तो आपको मास्टर शाखा के लिए एक पुल अनुरोध बनाना होगा। फिर "स्वीकृति" पर क्लिक करने से पहले कम से कम एक, या इससे भी बेहतर, दो लोगों को इस कोड को देखना चाहिए। आम तौर पर, प्रोजेक्ट की टीम लीड और दूसरे व्यक्ति को निश्चित रूप से देखना चाहिए। तब आप पुल अनुरोध को पूरा कर सकते हैं। GitHub Flow को परियोजनाओं में निरंतर वितरण (CD) चलाने के लिए भी जाना जाता है। ऐसा इसलिए है क्योंकि जब परिवर्तन मुख्य शाखा में जाते हैं, तो उन्हें तुरंत सर्वर पर तैनात किया जाना चाहिए।

गिटफ्लो

पिछली रणनीति (GitHub Flow) अपने मूल में बहुत जटिल नहीं है। दो प्रकार की शाखाएँ हैं: मास्टर और फ़ीचर शाखाएँ। लेकिन GitFlow अधिक गंभीर है। कम से कम, ऊपर दी गई तस्वीर से यह स्पष्ट हो जाना चाहिए :) तो यह रणनीति कैसे काम करती है? सामान्य तौर पर, GitFlow में दो लगातार शाखाएँ और कई प्रकार की अस्थायी शाखाएँ होती हैं। गिटहब फ्लो के संदर्भ में, मास्टर शाखा लगातार है और अन्य अस्थायी हैं। लगातार शाखाएँ

• मास्टर: इस शाखा को किसी को कुछ भी छूना या धक्का नहीं देना चाहिए। इस रणनीति में, मास्टर नवीनतम स्थिर संस्करण का प्रतिनिधित्व करता है, जिसका उपयोग उत्पादन में किया जाता है (अर्थात वास्तविक सर्वर पर)
• विकास: विकास शाखा। यह अस्थिर हो सकता है।

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

1. फ़ीचर शाखाएँ - नई कार्यक्षमता विकसित करने के लिए।
2. रिलीज शाखाएं - परियोजना के एक नए संस्करण की रिलीज की तैयारी के लिए।
3. हॉटफ़िक्स शाखाएँ - वास्तविक सर्वर पर वास्तविक उपयोगकर्ताओं द्वारा पाई गई बग को जल्दी से ठीक करने के लिए।

फ़ीचर शाखाएँ

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

शाखाओं को मुक्त करें

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

हॉटफ़िक्स शाखाएँ

हॉटफ़िक्स शाखाएँ भी मास्टर शाखा के लिए एक नया संस्करण जारी करने के लिए होती हैं। फर्क सिर्फ इतना है कि उन रिलीज की योजना नहीं है। ऐसी स्थितियाँ होती हैं जब बग जारी किए गए संस्करण में आ जाते हैं और उत्पादन वातावरण में खोजे जाते हैं। आईओएस को लें: जैसे ही एक नया संस्करण जारी किया जाता है, आपको तुरंत अपडेट का एक गुच्छा मिलता है जिसमें रिलीज के बाद पाए गए बग के लिए फिक्स होते हैं। तदनुसार, हमें जल्दी से बग को ठीक करने और एक नया संस्करण जारी करने की आवश्यकता है। हमारी तस्वीर में, यह संस्करण 1.0.1 से मेल खाती है। विचार यह है कि वास्तविक सर्वर (या जैसा कि हम कहते हैं, "उत्पादन में" या "उत्पादन में") पर बग को ठीक करने के लिए आवश्यक होने पर नई कार्यक्षमता पर काम बंद नहीं करना पड़ता है। मास्टर शाखा से हॉटफ़िक्स शाखा बनाई जानी चाहिए, क्योंकि यह वर्तमान में उत्पादन में चल रही चीज़ों का प्रतिनिधित्व करती है। जैसे ही बग फिक्स तैयार हो जाता है, इसे मास्टर में विलय कर दिया गया है, और एक नया टैग बनाया गया है। रिलीज़ ब्रांच को तैयार करने की तरह, एक हॉटफ़िक्स ब्रांच को भी अपने फिक्स को वापस डेवलपमेंट ब्रांच में मर्ज कर देना चाहिए।

फोर्किंग वर्कफ़्लो

फोर्किंग वर्कफ़्लो में, विकास में दो रिपॉजिटरी शामिल हैं:

1. मूल रिपॉजिटरी, जिसमें सभी बदलाव मर्ज किए जाएंगे।
2. एक कांटा भंडार। यह मूल रिपॉजिटरी की एक प्रति है, जिसका स्वामित्व किसी अन्य डेवलपर के पास है, जो मूल में परिवर्तन करना चाहता है।

अब तक थोड़ा अजीब लगता है, है ना? जो कोई भी पहले से ही ओपन-सोर्स डेवलपमेंट का सामना कर चुका है, वह पहले से ही इस दृष्टिकोण से परिचित है। यह रणनीति निम्नलिखित लाभ देती है: मूल शाखा में संयुक्त विकास के लिए अनुमति दिए बिना फोर्क रिपॉजिटरी में विकास हो सकता है। स्वाभाविक रूप से, मूल रिपॉजिटरी के मालिक को प्रस्तावित परिवर्तनों को अस्वीकार करने का अधिकार है। या उन्हें स्वीकार करने और विलय करने के लिए। यह मूल रिपॉजिटरी के मालिक और डेवलपर दोनों के लिए सुविधाजनक है जो उत्पाद बनाने में मदद करना चाहता है। उदाहरण के लिए, आप Linux कर्नेल में परिवर्तनों का सुझाव दे सकते हैं । यदि लिनस फैसला करता है कि वे समझ में आते हैं, तो परिवर्तन जोड़े जाएंगे (!!!)

फोर्किंग वर्कफ़्लो का एक उदाहरण

गिटहब पर फोर्किंग वर्कफ़्लो लागू किया जाता है जब कोई लाइब्रेरी होती है जिसका आप उपयोग करना चाहते हैं। इसमें एक बग है जो आपको इसे पूरी तरह से उपयोग करने से रोकता है। मान लीजिए कि आप समस्या में काफी गहराई तक जाते हैं और समाधान जानते हैं। फोर्किंग वर्कफ़्लो का उपयोग करके, आप लाइब्रेरी के मूल रिपॉजिटरी में काम करने के अधिकार के बिना समस्या को ठीक कर सकते हैं। आरंभ करने के लिए, आपको कुछ रिपॉजिटरी का चयन करना होगा, उदाहरण के लिए, स्प्रिंग फ्रेमवर्क । ऊपरी दाएं कोने में "कांटा" बटन ढूंढें और क्लिक करें: इसमें कुछ समय लगेगा। फिर आपके व्यक्तिगत खाते में मूल रिपॉजिटरी की एक प्रति दिखाई देगी, जो इंगित करेगी कि यह एक कांटा है:अब आप इस रिपॉजिटरी के साथ हमेशा की तरह काम कर सकते हैं, मास्टर ब्रांच में बदलाव जोड़ सकते हैं, और जब सब कुछ तैयार हो जाता है, तो आप मूल रिपॉजिटरी के लिए एक पुल अनुरोध बना सकते हैं। ऐसा करने के लिए, न्यू पुल अनुरोध बटन पर क्लिक करें:

कौन सी रणनीति चुननी है

गिट एक लचीला और शक्तिशाली टूल है जो आपको विभिन्न प्रकार की प्रक्रियाओं और रणनीतियों का उपयोग करके काम करने देता है। लेकिन आपके पास जितने अधिक विकल्प होंगे, यह तय करना उतना ही कठिन होगा कि कौन सी रणनीति चुनें। यह स्पष्ट है कि सभी के लिए एक ही उत्तर नहीं है। सब कुछ स्थिति पर निर्भर करता है। उस ने कहा, ऐसे कई दिशानिर्देश हैं जो इसमें मदद कर सकते हैं:

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

गिट में ब्रांचिंग रणनीतियों के बारे में मैं यही कहना चाहता था। आपके ध्यान के लिए धन्यवाद :) GitHub पर मेरा अनुसरण करें , जहां मैं अक्सर अपनी रचनाएं पोस्ट करता हूं जिसमें विभिन्न तकनीकों और उपकरणों का उपयोग होता है जो मैं अपने काम में उपयोग करता हूं।