मैं एक Git वर्कफ़्लो चुनने की कोशिश कर रहा हूं जो हमारे उत्पाद के लिए सबसे उपयुक्त है। यहाँ पैरामीटर हैं:
- हम एक साल में कुछ प्रमुख रिलीज करते हैं, चलो 10 को सबसे ज्यादा कहते हैं
- हमारे पास एक ही समय में हमारे उत्पाद के कई संस्करण सक्रिय हैं (कुछ लोग v10.1 पर हैं, कुछ v11.2 पर हैं, आदि)
- हमें एक ही समय में कई रिलीज पर काम करने में सक्षम होना चाहिए (इसलिए हम v12.1 पर काम कर सकते हैं, लेकिन जैसे-जैसे हम रिलीज के अंत में आते हैं, हम उसी समय v12.2 पर काम करना शुरू कर देते हैं)
- महत्वपूर्ण कीड़े पाए जाने पर हमें रिलीज़ रिलीज़ करने में सक्षम होना चाहिए
अब तक, यहां मुझे लगता है कि यह काम कर सकता है:
- सिंगल रिमोट रेपो का उपयोग किया जाता है
- मास्टर से शाखा 12.1 बनाएँ
- 12.1 के आधार पर सुविधा शाखाएं बनाएं, उन्हें कमिट करें और 12.1 में वापस मर्ज करें, पुश करें
- एक बार जब हमें भविष्य की रिलीज़ पर काम करना शुरू करना है, तो 12.1 के आधार पर एक नई शाखा 12.2 बनाएं
- तब से, 12.1 के लिए एक सुविधा पर काम करते समय, 12.1 से शाखा बनाएं, परिवर्तन करें, और 12.1 और 12.2 दोनों में विलय करें, पुश करें
- यदि 12.2 के लिए एक सुविधा पर काम कर रहे हैं, तो 12.2 से शाखा बनाएं, परिवर्तन करें, और केवल 12.2 में विलय करें, धक्का दें
- जब रिलीज़ 12.1 पूरा हो जाता है, तो इसे मास्टर में जोड़ें और 12.1 के साथ मास्टर शाखा को टैग करें
- यदि किसी हॉटफ़िक्स की आवश्यकता है, तो सबसे पुरानी रिलीज़ ब्रांच से एक हॉटफ़िक्स ब्रांच बनाएं जिसकी उसे ज़रूरत हो, उसमें बदलाव करें और उस रिलीज़ के लिए सभी रिलीज़ ब्रांचों में विलय कर दें और भविष्य में रिलीज़ होने वाली ब्रांच प्रभावित हो सकती है; यदि नवीनतम स्थिर रिलीज़ शाखा प्रभावित हुई, तो इसे मास्टर में मर्ज कर दें।
मुझे कुछ चिंताएँ हैं:
- मुझे यकीन नहीं है कि पुरानी शाखाओं से नई शाखाओं में विलय विलय एक सुचारू प्रक्रिया होगी, खासकर अगर अतिव्यापी परिवर्तन हुए हैं; क्या यह उन मामलों में प्रत्येक शाखा में मैन्युअल रूप से केवल हॉटफ़िक्स के लिए हो सकता है, जहां यह दिखता है कि संघर्ष होगा
- मैंने जो वर्कफ़्लो मॉडल देखे हैं, वे लगता है कि रिलीज़ ब्रांच को ज़्यादा ज़िंदा नहीं रखेंगे, एक बार रिलीज़ होने के बाद मास्टर, टैग और मर्ज में विलीन हो जाता है। इसके साथ मेरी समस्या यह है कि मुझे यह पता नहीं है कि रिलीज की स्थिति को कैसे प्रबंधित किया जाए यदि मेरे पास मास्टर में टैग हैं, तो एक शाखा में हॉटफ़िक्स करना आसान लगता है और फिर मेरे पास एक रिलीज़ है जो मैं हमेशा वापस जा सकता हूं जिसमें नवीनतम हॉटफ़िक्स है (मैं रिलीज़ में भी हॉटफ़िक्स को टैग कर सकता हूं)। निश्चित नहीं है कि मैं मास्टर के भीतर वापस जा सकता हूं और किसी भी तरह से जारी की गई कॉपी की कॉपी है और उस टैग को अपडेट करना है।
टिप्पणियों को उन चीजों पर सराहना की जाती है जिन्हें मैंने अनदेखा किया है या जिन चीजों को मैंने निर्दिष्ट किया है, उन्हें पूरा करने के बेहतर तरीके।
4
nvie.com/posts/a-successful-git-branching-model
—
विल्बर्ट
मुझे git-flow के बारे में पता है, लेकिन मैं यह नहीं देखता कि यह कई सिमुलैटिक रिलीज़ पर कैसे काम करता है। लगता है कि रिलीज शाखाओं की तरह वास्तव में कोई भी काम करने के लिए नहीं किया जाता है, ज्यादातर सफाई और फिर मर्ज और टैग करने के लिए। जब मेरे पास 4 भिन्न रिलीज़ संस्करणों को प्रभावित करने वाला एक हॉटफ़िक्स है तो मैं क्या करूँ? मुझे लगता है कि मैं मास्टर से टैग की गई रिलीज़ को चेकआउट कर सकता हूं, लेकिन एक बार जब मैंने इसे ठीक कर लिया है, तो उस विशेष रिलीज के लिए मैंने मास्टर में जो भी सुधार किए हैं, मैं उन्हें फिर से कैसे काम करूंगा। लगता है जैसे यह मुश्किल होगा।
—
रॉकेट 04
यदि आपको एक ही फिक्स के साथ कई रिलीज को गर्म करने की आवश्यकता है, तो आपको संभवतः सबसे पुराना संस्करण पहले से ठीक करना चाहिए और प्रत्येक रिलीज के लिए फिट होने के लिए नया, विलय करना चाहिए। यदि आप नए से पुराने काम करते हैं तो आप बाद में रिलीज से निर्भरता को कम करने का जोखिम उठाते हैं जो चीजों को जटिल करेगा।
—
axl
और जैसा कि मैंने अपने प्रस्तावित उत्तर में उल्लेख किया है, मास्टर शाखा कई लाइव रिलीज़ के साथ इतनी अच्छी तरह से काम नहीं करती है, इसलिए जब तक आपको वास्तव में किसी कारण से इसकी आवश्यकता नहीं होती है, मैं आपको सलाह देता हूं कि इसका उपयोग न करें।
—
एक्सल