2012-04-06 10 views
7

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

दस्तावेज़ से पता चलता है कि फीचर शाखाएं आम तौर पर डेवलपर के लिए स्थानीय होती हैं जो मैंने कहीं और पढ़ी है। हालांकि, कुछ इंजीनियर ऐसी सुविधाओं पर काम कर रहे हैं जो अगली रिलीज में नहीं होंगे। ये रिलीज हमारे रिलीज चक्र से पहले 2 से 3 पुनरावृत्तियों हैं।

मेरे इंजीनियरों से जो चिंता मैं सुनता हूं वह यह है कि वे इतने सारे कोड स्थानीय रखने के बारे में चिंतित हैं। यहां तक ​​कि उनकी बैकअप प्रक्रियाओं के साथ, यह अभी भी एक चिंता है। और मैं उनकी चिंताओं से सहमत हूं।

तो मेरा सवाल यह है कि, क्या यह मानक है कि अधिक तत्काल रिलीज के लिए स्लेटेड नहीं होने वाली शाखाओं को मूल में धक्का दिया जा सकता है? कुछ बिंदु पर इन शाखाओं को विकास शाखा में विलय कर दिया जाता है और फिर मूल से हटा दिया जाता है।

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

यदि यहां कोई बेहतर अभ्यास है तो कृपया मुझे मेरी अटकलें बताएं या पुष्टि करें।

उत्तर

4

यह निर्भर करता है।

यदि कोई सुविधा पर काम कर रहा है और इसे अन्य देवताओं के साथ साझा करना चाहते हैं तो यह पूरी समझ में आता है। लेकिन अगर यह एक विशेषता है कि आप अकेले काम कर रहे हैं, तो सर्वर को धक्का क्यों दें यदि आपको इसे साझा करने की आवश्यकता नहीं है? अंततः यह मास्टर की तरह किसी अन्य शाखा में विलय हो जाएगा या सुविधा पूरी होने पर विकसित होगी।

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

+0

मैं ये सब समझता हूं और यह मेरे लिए सही मायने रखता है। हालांकि, अगर इंजीनियर कुछ कोड पर काम कर रहा है जो पूरा होने में कुछ हफ्तों लग सकता है, तो क्या यह मूल को धक्का देने के लिए समझ में नहीं आता है ताकि कोड अप्रत्याशित परिस्थितियों से सुरक्षित हो? – Gregg

+0

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

+0

गोचा। और यही वह दृष्टिकोण है जिसे हम ले रहे हैं, मुझे लगता है। लंबे समय तक रहने वाली शाखाएं (सप्ताह या अधिक) शायद धक्का देना चाहेंगे। अल्पकालिक (दिन) स्थानीय हैं। यह मुझे पसंद है। मैं सिर्फ अपने लोगों को गलत रास्ते से प्रशिक्षित नहीं करना चाहता था। धन्यवाद। – Gregg

2

छोटे आकार की सुविधाओं के लिए इसके वैकल्पिक। मैं बैकअप उद्देश्यों के लिए दैनिक आधार पर मध्यम-बड़े आकार की विशेषताओं को धक्का देने की अनुशंसा करता हूं। आपकी कंपनी यह सुनकर नफरत करेगी कि आपके पीसी की मृत्यु हो जाने पर आपके डेवलपर ने 2 सप्ताह का काम बर्बाद कर दिया था।

संबंधित मुद्दे