गिट गैर-गुरु के लिए एकाधिक रिलीज लाइनों और गिट-फ्लो पर सलाह

Question

हमारे सॉफ़्टवेयर उत्पाद लाइन को कई सॉफ़्टवेयर संस्करणों को एक साथ विकसित करने और बनाए रखने की आवश्यकता है। हम रिश्तेदार गिट न्यूबीज हैं और हाल ही में Driessen's branching model का लाभ उठाने के लिए गिट फ्लो को अपनाया है। हमारे पास कुछ समर्पित डेवलपर्स के साथ एक बहुत छोटी सॉफ्टवेयर टीम है (हम सभी कई टोपी पहनते हैं) और कोई "एकीकरण गुरु" नहीं है।

अधिकतर खोज ने गिट और गिट फ्लो को हमारी आवश्यकताओं के अनुरूप अनुकूलित करने के बारे में थोड़ी सी विशिष्ट सलाह दी है। क्या हुआ है कि गिट फ्लो समवर्ती रूप से कई संस्करणों का समर्थन करने के लिए उपयुक्त नहीं है। एक related discussion on SO में अलग-अलग संस्करणों के इतिहास को ट्रैक करने के लिए अलग-अलग शाखा नामों का उपयोग करने के लिए उपयोग किए जाने वाले उत्तर हैं। यह, और संबंधित रणनीतियों, गिट फ्लो को तब तक समाप्त करती है जब तक यह संशोधित न हो; हमारी टीम की सीमाओं को एक कारण के लिए देखें कि यह हमारे लिए व्यावहारिक क्यों नहीं है।

मुख्य प्रश्न यह है कि कई रिलीज लाइनों का समर्थन करते समय ड्रिसेन के ब्रांचिंग मॉडल को जितनी जल्दी हो सके लागू करने के लिए दूसरों को एक अच्छा दृष्टिकोण मिल गया है?

अद्यतन:

अधिक लक्षित खोज और कुछ ही विकल्प पर आंतरिक विचार-विमर्श निम्नलिखित समाधान है कि हम कार्यान्वित कर रहे हैं की ओर जाता है के साथ नीचे (विशेष रूप से @Rasmus ') जवाब आसवन, और जो मैं एक दृष्टिकोण के रूप में प्रस्तुत करते हैं कि हो सकता है समान स्थितियों के तहत समान टीमों के लिए प्रासंगिक हो।

हम गिट फ्लो का उपयोग जारी नहीं रखेंगे। इसके बजाय, हम Driessen के मॉडल प्रत्येक व्यक्ति रिहाई लाइन के लिए एक रेपो में उसके इच्छित रिहाई तार के साथ प्रत्येक शाखा नाम prefacing द्वारा, उदा लागू होगी .:

r1.5/develop 

एक परियोजना के सभी संस्करणों Git भंडार में शामिल हैं। एक नए प्रोजेक्ट संस्करण को शुरू करने में रिलीज स्ट्रिंग (उदा। r1.6/develop) और हमारे मामले में r1.6/release; master एकल वर्तमान अच्छे बिल्ड करने योग्य राज्य के निहितार्थ के साथ नई दीर्घकालिक शाखाओं का एक छोटा सेट बनाने का होता है।

हम एक सर्वर है कि स्थानीय रेपो remote लिंक के माध्यम से कोड साझा करने के लिए मुख्य एवेन्यू हो जाएगा पर परियोजना प्रति एक केंद्रीय सार्वजनिक भंडार की स्थापना। इस भंडार के लिए एक धक्का कोड को इंगित करता है जो दूसरों द्वारा उपभोग करने के लिए तैयार है। RX.Y/develop को विलय करना और फिर RX.Y/release शाखा को धक्का देना कोड को इंगित करता है जो रिलीज़ के लिए है। feature, hotfix, et। अल। शाखाओं को समान रूप से संभाला जाता है। दी गई रिलीज लाइन के लिए शाखा विलय/प्रतिबद्ध इतिहास स्वच्छ और समझदार है। हम नहीं चाहते हैं कि ठेठ गिट वितरित रेपो रणनीति को इस तरह के रिपोज़ विलय की जटिलता से बचने के पक्ष में वितरित करें, समय के साथ, संरचना में अलग होने की संभावना है।

कुछ गिट जीयूआई (उदाहरण के लिए स्रोत ट्री) में इस शाखा संरचना को श्रेणीबद्ध के रूप में पहचाना और प्रदर्शित किया जाता है, जो शाखा संरचना से किसी परियोजना के शीर्ष-स्तरीय इतिहास को समझने में मदद करता है।

किसी भी उत्तर को अप-वोट करने के लिए क्षमा नहीं; एसओ पर मेरी प्रतिष्ठा अभी तक ऐसा करने की न्यूनतम आवश्यकता नहीं है।

Answer 1

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

हम इसे बांट दिया है तो हम एक प्रारंभिक रेफरी की तरह refs/सिर/platformX.Y/तो हम उस

तो तुम आप platformX चेकआउट क्या करने की जरूरत पर निर्भर करता है पर निर्माण किया है।वाई/एक फीचर शाखा पर उस बिंदु से काम करना शुरू करें और शुरू करें और जब आप पूरा कर लेंगे तो आप विकास के लिए वापस विलय करें।

यह हमारे लिए काम करता है और हम nvie मॉडल का अनुसरण कर सकते हैं।

सब कुछ हम अपने मुख्य विकसित शाखा को इन सभी platformX.Y शाखा विलय कर रहे हैं ताकि उन शाखाओं पर सुधारा त्रुटियों के रूप में अच्छी तरह से नवीनतम सॉफ्टवेयर करने के लिए जारी कर रहे हैं के शीर्ष पर

।

Answer 2

एक समाधान config चर gitflow.branch.develop बदलने के लिए है। आप अपने जारी संस्करण में एक ब्रंच बनाते हैं और उस शाखा का उपयोग अपनी नई विकास शाखा के रूप में करते हैं। वहां से, आप सामान्य गिट-फ्लो कमांड का उपयोग करते हैं। यदि आप स्वचालित रूप से मूल कार्य शाखा में उस कार्य को विलय करना चाहते हैं, तो गिट-फ्लो फिनिश कमांड से पहले gitflow.branch.develop चर बदलें।

Answer 3

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

उदाहरण के लिए, हमारी अगली सामान्य रिलीज 23.0 है, और हमारी विशेष, "सैंडबॉक्स" रिलीज 22.4.2 है। इन मामलों के लिए, हम:

1. प्रारंभिक रूप से, नई सुविधाओं के निर्माण से पहले, विकास के विशेष रिलीज के लिए रिलीज शाखा 22.4.2 बनाएं। यह ठीक है अगर कुछ विशेषताओं को तब तक शुरू किया गया था जब तक कि वे विकास पर किसी भी काम के बाद नहीं आते हैं जिसे हम बाहर करना चाहते हैं।
2. सुविधा (शुरू-22.4.2)
3. प्रारंभ शुरू 22.4.2 के साथ प्रत्येक नए 22.4.2 सुविधा (विकसित पर एक changeset) के रूप में यह माता-पिता/आधार है के लिए वहाँ एक टैग करें। यह रिलीज शाखा पर लीक होने के दौरान विकसित होने के लिए विलय किए गए किसी भी काम को रोकता है। git flow feature start के लिए टिप के अलावा माता-पिता को चुनने के लिए कमांडलाइन और सॉर्सेट्री दोनों समर्थन।
4. , सुविधा के लिए 22.4.2 शाखा की नोक से मैन्युअल रूप से मर्ज अगर वांछित, और जितनी बार चाहें, शाखा से किसी भी पूरा सुविधाओं में लाने के लिए। यह हमें शाखा पर नई 22.4.2 सुविधाओं के बीच चिंता के किसी भी इंटरैक्शन से निपटने देता है।
5. git flow feature finish सुविधा है, जो इसे सामान्य रूप में विकसित करने के लिए विलीन हो जाती है। (हमारे लिए, भविष्य के रिलीज में शामिल होने के लिए हैं। हम केवल कम परीक्षण वाले काम से 22.4.2 की रक्षा कर रहे हैं।)
6. finish के बाद, हम सुविधा के बंद होने से पहले अंतिम परिवर्तन को मैन्युअल रूप से मर्ज करते हैं 22.4.2 शाखा पर।