संस्करण नियंत्रण सॉफ्टवेयर में रखरखाव के विकास से वर्तमान विकास को अलग करने के लिए अनुशंसित तरीका क्या है?

Question

मेरे पास कुछ सॉफ्टवेयर एप्लिकेशन हैं जो Git का उपयोग करने में कामयाब हैं। मैंने अभी एक नया संस्करण 2.x जारी किया है, जिसे मैं दीर्घकालिक (बग फिक्स ज्यादातर) पर बनाए रखने की योजना बना रहा हूं। इस बीच, मैं संस्करण 3.x पर काम करना शुरू करना चाहूंगा। इसे प्रबंधित करने का अनुशंसित तरीका क्या है? क्या मुझे संस्करण 2.x के लिए एक शाखा बनानी चाहिए और मास्टर पर 3.x विकास करना चाहिए? या दूसरा तरीका?

Comments

विकास और स्थिर के लिए एक अलग शाखाएँ हैं।

— Oded

तो आमतौर पर मास्टर शाखा में क्या जाता है? (अब तक मैं हमेशा वहाँ सब कुछ करना)

— लौरेंत

आपको यह तय करने की आवश्यकता है कि आप क्या masterमतलब चाहते हैं । यह सिर्फ एक लेबल है।

— Oded

Answer 1

चीजों को करने का एक बहुत ही दिलचस्प तरीका यहाँ वर्णित किया गया था: एक सफल गिट ब्रांचिंग मॉडल

मुझे यह बहुत पेचीदा लगा, लेकिन वास्तव में इसका उपयोग करना अभी बाकी है।

बहुत अच्छी तरह से, के रूप में अनुरोध किया है (बहुत) लेख क्या कहता है की छोटी राशि:

• मास्टर शाखा केवल प्रत्येक समाप्त मील के पत्थर का प्रतिनिधित्व करती है (अर्थात संस्करण 1.0, 1.1, 1.2 आदि)
• विकास स्वयं की शाखा में किया जाता है (आसानी से "विकसित" नाम दिया गया है, जिसने सोचा होगा?)। जब भी फीचर पूर्ण संस्करण किया जाता है, तो विकसित शाखा को मास्टर शाखा में वापस मिला दिया जाता है।
• विकास से दूर शाखाएं शाखाएं हैं। ये अगले (या किसी भी भविष्य) रिलीज़ के लिए एकल सुविधाओं का प्रतिनिधित्व करते हैं। वे विकसित शाखा के साथ वापस विलय कर देते हैं।
• विकास से आने वाली एक और शाखा "रिलीज" शाखा है। यह एक शाखा है जो लगभग पूर्ण रिलीज संस्करण का प्रतिनिधित्व करती है जहां केवल मामूली विवरण को साफ करना पड़ता है। यह विकास शाखा और अंततः मास्टर शाखा के साथ विलय हो जाता है
• यदि आप अपनी रिलीज़ में से एक में एक गंभीर बग पाते हैं, तो मास्टर शाखा से "हॉटफ़िक्स" की शाखाएँ (यानी "यदि उपयोग कोनाम कोड में प्रवेश करता है तो हमारा प्रोग्राम मुख्य हार्डड्राइव को रिफॉर्मेट करेगा ...")। यह बग्गी रिलीज से शाखाओं और, जब ठीक हो जाता है तो वापस मास्टर शाखा और डिवेलपमेंट शाखा में विलय कर दिया जाता है।

यह इसकी कमी है, लेकिन मुझ पर विश्वास करो, कि लेख इसे और अधिक विस्तार से वर्णन करता है, और सहायक दृश्य ग्राफिक के साथ इसे समझना बहुत आसान है।

Comments

आपको उत्तर में अपने सुझाव पर कुछ स्पष्टीकरण शामिल करना चाहिए, अधिमानतः लोगों को मॉडल के समग्र विचार प्राप्त करने के लिए लिंक का पालन नहीं करना होगा। लिंक में अशुभ होने की बुरी आदत होती है, और उत्तर अपने दम पर खड़े होने चाहिए ...

— yannis

+1 बहुत ज्यादा हम जो काम में उपयोग करते हैं, और यह वास्तव में काम करता है।

— एड जेम्स 10

मेरा मानना ​​है कि इसे आमतौर पर "स्थिर ट्रंक" या "सुविधा शाखा" मॉडल के रूप में संदर्भित किया जाता है।

— sleske

"मास्टर शाखा केवल प्रत्येक समाप्त मील के पत्थर का प्रतिनिधित्व करती है (अर्थात संस्करण 1.0, 1.1, 1.2 आदि)" मैं संस्करण 1.0, 1.1, 1.2, 2.0, 1.3, 2.1, 1.4, 2.2, 3.0, 1.5 के साथ एक मास्टर शाखा नहीं चाहूंगा। यह आदेश, यह वास्तव में भ्रामक होगा। मेरा अनुमान है कि एक निहित धारणा है कि ज्यादातर एक स्ट्रीम में है जिस पर रिलीज की जाती है, मेरे व्यवहार में ऐसा नहीं है। शुरुआती दत्तक ग्रहण करने वाले लोग हैं और कुछ अधिक स्थिर चाहते हैं।

— एपीग्रामग्राम

खैर, लंबे समय में एक शाखा और कुछ नहीं है तो एक लेबल है जिससे आपको पता चल सके कि वहां क्या हो रहा है। इसलिए यदि आप इसे इस तरह से पसंद नहीं करते हैं, तो केवल महापौर स्थिर रिलीज के लिए मास्टर शाखा का उपयोग करने और छोटे वृद्धिशील रिलीज के लिए "ट्रायल" शाखा (या जिसे आप इसे कॉल करना चाहते हैं) होने से कुछ भी नहीं रोक रहा है।

— सोरसी

Answer 2

मेरा सिद्धांत यह है कि शाखा जितनी अधिक अल्पावधि की होगी, शाखा संरचना में उतनी ही गहरी होनी चाहिए और उसका नाम जितना विशिष्ट होगा। लंबी अवधि शाखा है, यह शाखा संरचना में होगी और इसका नाम अधिक सामान्य होगा।

तो आप अपने मास्टर को लंबे समय तक (3.X) संस्करण के लिए रखते हैं और आप इस शाखा का नाम जेनेरिक नाम (मास्टर, ट्रंक, डेवेल, ...) के साथ रखते हैं और न कि एक विशिष्ट (रिलीज़ कोड नाम या इससे भी बदतर रिलीज़ नंबर। जो देर से विपणन निर्णय पर व्यवहार में बहुत निर्भर हैं)

यह एक सिस्टम में इतना मायने नहीं रखता है जैसे git जिसमें शाखाओं के लिए एक फ्लैट नाम स्थान होता है और जहाँ शाखाएँ बराबर होती हैं। यह क्लियरकेस जैसी प्रणाली के साथ अधिक मायने रखता है जिसमें शाखाओं के लिए एक श्रेणीबद्ध नाम स्थान है (V4 शाखा का पूरा नाम मुख्य / v1 / v2 / v3 / v4 ...)

Comments

+1 को छोड़कर मुझे नहीं पता कि इस संदर्भ में वास्तव में गहरे और उथले का क्या मतलब है, शायद आप उन शर्तों पर थोड़ा विस्तार कर सकते हैं?

— माइकल डुरंट

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

— एपीग्रामग्राम