सरल गिट रिलीज प्रबंधन

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

इस समस्या को कैसे हल करें

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

हॉटफिक्स शाखा का परिचय

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

आखिर में हमारे पास क्या है

समाधान के मुख्य लाभ:

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

नुकसान में पिछले प्रमुख रिलीज में हॉटफिक्स को जारी करने में असमर्थता शामिल है। केवल आवश्यक कमिट्स से ही रिलीज को डायल करना असंभव है। यह जटिल प्रवाह द्वारा हल किया गया है और इस लेख के दायरे से परे है।

कई लोगों के लिए, यहां कुछ भी नया नहीं है, लेकिन एक ही गीथूब द्वारा देखते हुए, अधिकांश ओपन-सोर्स प्रोजेक्ट एक शाखा के साथ सबसे सरल योजना का उपयोग करते हैं।

और आप किस प्रवाह का उपयोग करते हैं?

उपयोगी लिंक: ProGit , Git कैसे करें