उत्पादों के लिए एक सभ्य गिट ब्रांचिंग मॉडल जो दूसरे, तीसरे पक्ष के उत्पाद के संस्करण के साथ होना चाहिए (और एक प्रस्ताव के पेशेवरों और विपक्ष)

Question

नोट: मेरा प्रश्न मेरी विशिष्ट समस्या (जिसमें लाइफ़रे शामिल है) में केंद्रित है, लेकिन मुझे आशा है कि यह किसी के लिए भी उपयोगी हो सकता है जिसे एक ही परियोजना के विभिन्न संस्करणों को बनाए रखने की आवश्यकता है।

मैं एक कंपनी पर काम करता हूं, जो लाइफ़रे पोर्टल के लिए बहुत सारे प्लगइन्स लिखती है । ये प्लगइन्स (पोर्टल्स, थीम आदि) आमतौर पर पुन: प्रयोज्य हैं और निश्चित रूप से, पोर्टल के नए संस्करणों के लिए अपडेट किए जाने चाहिए।

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

ये आवश्यकताएं हमारे काम को जटिल बनाती हैं लेकिन, सौभाग्य से, हम कुछ सरलीकरण मान सकते हैं। उदाहरण के लिए, प्लगइन्स अक्सर एक समय में केवल एक प्रोग्रामर द्वारा अपडेट किए जाते हैं। एक ही समय में एक प्लगइन में दो या दो से अधिक सुविधाओं का होना बहुत दुर्लभ है।

अब, हम Gitorious की ओर पलायन कर रहे हैं । हम ऐसे परिदृश्य के लिए एक शाखा मॉडल की कल्पना करने की कोशिश कर रहे हैं।

मेरा मॉडल

मैंने जो प्रस्तावित किया वह था:

1. प्रत्येक प्लगइन में एक परियोजना के अंदर Gitorious में अपना स्वयं का भंडार होगा। उदाहरण के लिए, बिल्ली के बच्चे को प्रदर्शित करने के लिए एक पोर्टल परियोजना के kittens-portletअंदर एक भंडार होगा liferay-portlets।
2. एक नया प्लगइन बनाते समय, इसे लाइफ़रे संस्करण (उदाहरण के लिए lf5.2) के अनुसार नामित शाखा में बनाएँ ।
3. हर बार एक अपडेट प्लगइन पर किया जाता है, अपडेट को मंजूरी दी जाती है और उत्पादन में तैनात किया जाता है, प्लगइन को एक संस्करण के लिए टैग करता है (उदाहरण के लिए lf5.2v1, lf5.2v2आदि।) *।
4. हर बार एक प्लगइन को लाइफ़रे के नए संस्करण में पोर्ट किया जाना चाहिए, हम सबसे हालिया संस्करण (उदाहरण के लिए, शाखा lf6.0) को शाखा देते हैं ।
5. एक बार उत्पादन में, नई शाखा के प्रमुख को एक टैग प्राप्त होगा जैसे lf6.0v1।
6. जब भी हमें किसी क्लाइंट-विशिष्ट तरीके से किसी प्लगइन को कस्टमाइज़ करना होता है, तो हम क्लाइंट के नाम के साथ एक शाखा बनाते हैं (उदाहरण के लिए, हम lf5.2clientcorpअपने क्लाइंट "ClientCorp Inc." के लिए एक शाखा बनाएंगे)

यह एक असामान्य मॉडल है: इसकी कोई masterऔर नहीं बहुत-से-विलय वाली शाखाएँ होंगी । यह है कि मुझे लगता है कि इस तरह के मॉडल के साथ एक भंडार होगा:

एक मित्र ने इस प्रणाली को जटिल और त्रुटि-प्रवण पाया। उन्होंने उत्कृष्ट और लोकप्रिय विंसेंट ड्रिस्सेन मॉडल का सुझाव दिया , जिसे मैंने अभी भी प्रबंधन और अनुशासन-मांग के लिए कठिन पाया। यह बहुत अच्छा है (और परीक्षण!), लेकिन हमारी स्थिति के लिए बहुत जटिल लगता है।

मेरे दोस्त का मॉडल

तब उन्होंने एक और मॉडल का सुझाव दिया: हम लाइफ़रे संस्करण में प्रत्येक प्लगइन के लिए एक रिपॉजिटरी रखेंगे (इसलिए हम एक kittens-lf5.2-portletऔर फिर एक बनाना शुरू करेंगे kittens-lf6.0-portlet), प्रत्येक एक masterशाखा और एक developशाखा के साथ। masterहमेशा तैनाती के लिए तैयार हो जाएगा। (या यह दूसरा रास्ता हो सकता है, masterऔर stable, स्टीव लोश द्वारा सुझाए गए अनुसार )।

यह बहुत सरल है, लेकिन मुझे यह प्रणाली पसंद नहीं है:

1. इसके परिणामस्वरूप एक परियोजना में बहुत सारे भंडार हो सकते हैं, जिससे गॉइटियस को ब्राउज़ करना मुश्किल हो जाता है।
2. परियोजना की निर्देशिका का नाम प्रासंगिक है। यदि कोई रिपॉजिटरी को kittens-lf6.0-portletडायर पर क्लोन करता है और चींटी (हमेशा की तरह) के साथ डब्ल्यूएआर उत्पन्न करता है, तो डब्ल्यूएआर नाम भी होगा kittens-lf6.0-portlet। इस kittens-portletपोर्टल के पुराने संस्करणों ( उदाहरण के लिए नामित ) को एक उन्नत पोर्टल में अलग (और शायद लापता) पोर्टलेट के रूप में माना जाएगा। जरा सी देखभाल इससे बच सकती है लेकिन मैं इससे बचना पसंद करूंगा।
3. एक ही प्लगइन के विभिन्न संस्करणों को अलग रखा जाएगा। मैं अपना दिल तोड़ता हूँ :(
4. kittens-lf6.0-portlet मुझे लगता है कि एक भंडार के लिए एक बदसूरत नाम है।

मुझे दो अंतिम बिंदुओं पर संदेह है - जो दो और व्यक्तिपरक हैं, भी - मेरी अनिच्छा का मुख्य कारण हैं। बहरहाल, सभी चार आपत्तियां खड़ी हैं।

OTOH, मेरा अपना प्रस्ताव खुद को अजीब लगता है और मुझे आश्चर्य होता है कि क्या इस पर कोई छिपी हुई बगिया है। OT3rdH git इतना शक्तिशाली और लचीला है कि मुझे लगता है कि मुझे इसकी संभावनाओं को तलाशने में कोई शर्म नहीं होनी चाहिए।

इसलिए मैं पूछता हूँ:

1. सबसे अच्छा मॉडल क्या होगा? मेरा प्रस्ताब? मेरे दोस्त का मॉडल? अब पारंपरिक विन्सेन्ट Driessen प्रणाली?
2. आप किस अन्य ब्रांचिंग मॉडल का सुझाव देंगे?
3. अगर आपको लगता है कि मेरा मॉडल खराब है, तो आप ऐसा क्यों सोचते हैं? मैं यह जानना पसंद करूंगा कि कमियां और अंधे धब्बे क्या हैं।

* दरअसल, मैं कमिटमेंट को एक संस्करण के साथ टैग करना पसंद करूंगा, v1लेकिन जाहिरा तौर पर git में एक टैग को शाखा में बंद नहीं किया गया है - अर्थात, मैं 1 v1टैग नहीं कर सकता था lf5.2और दूसरे में lf6.0- तो मुझे नाम देना होगा डाली। क्या यह बीटीडब्ल्यू सही है?

Comments

आपके मॉडल में, आपको कितनी बार एक ही सुविधा या बग फिक्स को कई शाखाओं में जोड़ने की आवश्यकता है?

— कार्ल बेवेलफेल्ट

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

— ब्रांडीजी

Answer 1

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

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

अगर आपके प्रोजेक्ट को शाखाओं को विकास की मुख्य पंक्ति में वापस लाने की आवश्यकता है, तो Driessen मॉडल अच्छी तरह से काम करेगा, लेकिन आपको इसकी आवश्यकता नहीं है। यहां तक ​​कि मुझे लगता है कि यदि आप एक उत्पाद पर काम कर रहे हैं जो कि जी रहा है तो एक InDevelopment और StableRelease अवधारणा को बनाए रखने में योग्यता है।

इसलिए संक्षेप में मुझे लगता है कि आपका प्रोजेक्ट आपके ब्रांचिंग मॉडल के साथ-साथ आपके मेन लाइन के लिए Driessen के डैश के साथ अच्छा काम करेगा। आपकी माइलेज भिन्न हो सकती है; मैंने हमेशा एक "लंबित रिलीज़" शाखा के साथ काम किया है जो एक "लाइव" शाखा में बदल जाती है और एक अलग "अगली रिलीज़" होती है जिसमें सभी को विभिन्न बिंदुओं पर फिक्स और परिवर्तनों के क्रॉस परागण की आवश्यकता होती है, इसलिए मेरी धारणा पक्षपाती हो सकती है।

Answer 2

यह मुझे इस तथ्य से रोकता है कि प्रत्येक पोर्टलेट का अपना भंडार है (लेकिन आपकी कहानी पूरी नहीं हो सकती है)। व्यक्तिगत रूप से मैं प्रति प्रोजेक्ट एक रिपॉजिटरी बनाऊंगा। परियोजनाओं में अक्सर कई पोर्टलेट होते हैं और ये सभी लाइफ़रे के एक ही संस्करण के खिलाफ एक ही रन में बनते हैं। प्रत्येक परियोजना एक मौजूदा परियोजना की एक डुप्लिकेट हो सकती है जो लिफारे के एक अलग संस्करण के खिलाफ बनती है लेकिन मैं केवल एक उत्पाद को विभाजित करूंगा यदि अंतर बहुत बड़ा है। अगर एक निर्माण लाइफफेयर 5.1 और 5.2 के खिलाफ काम करता है तो मैं परियोजना को विभाजित नहीं करूंगा। मैं सब कुछ काम करने के लिए स्क्रिप्टिंग या मावेन (या दोनों) का उपयोग करूंगा। मैं प्रत्येक उत्पाद के प्रबंधन के लिए एक विकी (या ट्रेलो) का उपयोग करूंगा और इसके साथ जीवनरक्षक के किस संस्करण का निर्माण किया जा सकता है।

वैसे: मैं एक जावा प्रोग्रामर, मावेन विशेषज्ञ, बिल्ड विशेषज्ञ हूं और लाइफ़रे और अन्य पोर्टल सर्वर (आईबीएम वेबस्फेयर और ग्लासफिश) के साथ अनुभव है।

लेकिन यह सिर्फ मेरा € 0.02 है।