क्या एक ही सॉफ्टवेयर के विभिन्न संस्करणों को बनाए रखने के लिए शाखाओं का उपयोग करना एक अच्छा अभ्यास है?


72

हमारे पास एक ऐसा उत्पाद है जिसमें कुछ अलग संस्करण हैं। अंतर मामूली हैं: यहाँ और वहाँ अलग-अलग तार, एक में बहुत कम अतिरिक्त तर्क, दूसरे में तर्क में बहुत कम अंतर। जब सॉफ्टवेयर विकसित किया जा रहा है, तो प्रत्येक संस्करण में सबसे अधिक परिवर्तन करने की आवश्यकता है; हालाँकि, कुछ ऐसे हैं जो कुछ और अलग करने की आवश्यकता नहीं है। यदि मेरे पास रिलीज़-संस्करणए और रिलीज़-संस्करणबी (..सीटीसी) शाखाएँ हैं तो क्या यह शाखाओं का एक वैध उपयोग है? क्या कोई गोत्र हैं? अच्छे आचरण?

अद्यतन: सभी अंतर्दृष्टि के लिए धन्यवाद, यहाँ बहुत सारे अच्छे उत्तर। आम सहमति यह प्रतीत होती है कि इस उद्देश्य के लिए शाखाओं का उपयोग करना एक बुरा विचार है। किसी को भी आश्चर्य हो रहा है, समस्या का मेरा अंतिम समाधान विन्यास के रूप में तार को अलग करना है, और अलग-अलग तर्क को प्लगइन्स या स्क्रिप्ट के रूप में बाह्य करना है।


जवाबों:


45

यह परिवर्तन की परिमाण पर निर्भर करता है, लेकिन मैं आपके द्वारा वर्णित अंतर के लिए इसे अच्छा अभ्यास नहीं मानूंगा।

आम तौर पर, आप चाहते हैं कि एक गिट शाखा कुछ ऐसी हो जो भविष्य में विलय हो जाए या केवल पढ़ने के लिए संग्रहित हो। अनिश्चित रूप से हर किसी के लिए काम करने वाली सह-अस्तित्व वाली जीआईटी शाखाएं: परिवर्तन को प्रचारित और विलय करने की आवश्यकता है, संघर्षों को हल किया गया, सभी मज़ेदार। यदि और कुछ नहीं, तो प्रत्येक डेवलपर को एक के बजाय पांच रिपॉजिटरी में बदलाव को धकेलना याद रखना होगा।

यदि आपके पास छोटे परिवर्तन हैं, तो समस्या की तुलना में पूरे विलय और शाखा-रखने का प्रयास अधिक लगता है। संस्करणों के बीच अंतर करने के लिए अपने प्रीप्रोसेसर या बिल्ड सिस्टम का उपयोग करें। क्या एक सरल #ifdefचाल है? फिर git के साथ समस्याओं को हल न करें, यह ओवरकिल है।


4
मैं कहता हूं कि यह git के लिए सही है, लेकिन यह ध्यान रखना दिलचस्प है कि रिलीज़ / संस्करणों के लिए अन्य VCS शाखाओं में बंटना एक बेहतर रणनीति हो सकती है
jk।

16

यह वास्तव में क्या शाखाएं हैं। शाखाओं को आपके विकास की रेखा के मध्य-मध्य पक्ष के पथों के लिए छोटा माना जाता है, समान कोड के दीर्घकालिक समानांतर संस्करण नहीं।

मैं सभी अलग-अलग संस्करणों को एक ही शाखा में डालूंगा, जो कि संस्करणों के बीच अलग-अलग हिस्सों के लिए एक उपनिर्देशिका के साथ है, और अपनी बिल्ड प्रक्रिया सेट करें (आपके पास एक स्वचालित बिल्ड, राइट?) है ताकि यह मांग पर या तो संस्करण का उत्पादन कर सके? (या उन सभी को एक बार में)।

आखिरकार, आप "सच्चाई का एकल स्रोत" रखना चाहते हैं; शाखाओं के साथ, आप कुछ कोड डुप्लिकेट कर रहे होंगे, लेकिन सभी नहीं, और निश्चित मर्ज वास्तव में आपके सेटअप को तोड़ देंगे।


यदि थोड़े अंतर वाले एक ही वर्ग के दो संस्करण हैं, तो यहां एक स्वचालित निर्माण कैसे मदद करेगा? एकमात्र समाधान है कि मेरे मन में आता है कि (विभिन्न समाधान विन्यास का उपयोग कर रहा है EditionA, EditionBआदि) और सशर्त में कक्षाएं इस तरह सहित csprojफ़ाइलें (जैसे <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'EditionA|AnyCPU' ">)। स्वचालित बिल्ड प्रोजेक्ट बनाने के लिए इन विभिन्न कॉन्फ़िगरेशन का उपयोग कर सकते हैं। तुम क्या सोचते हो?
9

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

12

एक समाधान - जैसा कि लोगों ने बताया है - विभिन्न संस्करणों का समर्थन करने के लिए बिल्ड सिस्टम को कॉन्फ़िगर करना है।

मैं इसे फीचर टॉगल के रूप में लागू करने और कॉन्फ़िगरेशन फ़ाइल का उपयोग करने पर भी विचार करूंगा। जितना कम आपको निर्माण करना है, उतना बेहतर है।

इस साइट पर एक नज़र है।


3

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


2

यह विभिन्न बिल्ड कॉन्फ़िगरेशन के लिए एक नौकरी की तरह लगता है। Thiton का उत्तर इस दिशा में जाता है लेकिन मैं इसे इससे बहुत आगे ले जाऊंगा#ifdef :

सॉफ्टवेयर के विभिन्न संस्करणों के निर्माण के लिए विभिन्न बिल्ड लक्ष्यों का उपयोग करें। लक्ष्य भिन्न हो सकते हैं

  • कॉन्फ़िगरेशन में वे शामिल हैं,
  • ऑब्जेक्ट या स्रोत फ़ाइलों में वे शामिल हैं, या
  • स्रोत कोड का प्रीप्रोसेसिंग।

इस प्रीप्रोसेसिंग में स्पष्ट रूप से शास्त्रीय C प्रीप्रोसेसर शामिल हो सकते हैं, लेकिन यह कस्टम प्रेप्रोसेसर का उपयोग करके प्रवेश कर सकता है, कस्टम व्यू बनाने के लिए एक टेम्प्लेट इंजन ...

इस तरह, आप सक्रिय रूप से हर एक बदलाव को कई शाखाओं में धकेलने से बचते हैं, जो DRY का उल्लंघन करता है (बेशक यह भी स्वचालित हो सकता है लेकिन मुझे इसका फायदा नहीं दिखता)।


1

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


1

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

इसके अलावा, मुझे लगता है कि यह आपके पास विशेष रूप से तैनाती की विकास प्रक्रिया पर निर्भर करेगा। यदि आपके पास एक ऐसी प्रक्रिया है जो केवल एक शाखा को उत्पादन के लिए रोल आउट करने की अनुमति देती है और शाखाओं को "वृद्धिशील निर्माण" के रूप में माना जा रहा है, जिसका अर्थ है कि रिलीज बी को उत्पादन तक नहीं लुढ़काया जा सकता है, जब तक कि ए को पहले रोल आउट नहीं किया गया था, यह देखते हुए कि सभी परिवर्तन A पहले से ही B में है, फिर कई शाखाएँ होने का रास्ता है। यह तब काम करेगा जब आपके पास दुनिया भर में बिखरी हुई टीमें होंगी और आपके पास आमतौर पर प्राथमिकता के आधार पर बदलाव होंगे।


-2

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


1
ओपी एकल उत्पाद के विभिन्न शाखाओं के लिए अलग-अलग सुविधाओं के विकास के लिए नहीं, आदि के बारे में पूछ रहा है
एक CVn
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.