जब भी कोई नया प्रोजेक्ट शुरू होता है, तो आमतौर पर मास्टर के सीधे स्ट्रेट करने से शुरू होता है जब तक कि आपको कुछ "स्थिर" नहीं मिल जाता है, और फिर आप शाखाओं में काम करना शुरू कर देते हैं।
कम से कम, यह है कि मैं इसे सामान्य रूप से कैसे करता हूं। क्या दूसरी प्रतिबद्धताओं से तुरंत शाखाएं शुरू करने का एक तरीका है? क्या यह इस तरह से करने के लिए समझ में आता है? जाहिर है, "प्रारंभिक कमिट" हमेशा मास्टर पर होगी, लेकिन उसके बाद, मुझे कब पता चलेगा कि नई सुविधाओं के लिए शाखाएं बनाने का सही समय है?
जवाबों:
तुरंत ही।
मुख्य प्रश्न यह है कि मास्टर के लिए नीति क्या है। जीआईटी के साथ, आमतौर पर, मास्टर पर शाखा नीति बिल्डेबल स्टेबल रिलीज़ होती है। कभी-कभी, मास्टर 'मेनलाइन' होता है, जहाँ से शाखाओं को बनाया जाता है और विलय से पहले रिलीज़ शाखा में विलय कर दिया जाता है। ये दो अलग-अलग भूमिका / नीति दृष्टिकोण हैं।
यह अक्सर लोगों की भूमिका या परियोजना के माध्यम से शाखा के तरीके की नीति को बदलने के लिए त्रुटियों का एक स्रोत है। एकल डेवलपर के लिए इन परिवर्तनों को योगदानकर्ताओं तक पहुंचाना आसान है, लेकिन एक दर्जन प्रोग्रामर को यह पहचानने की कोशिश की जा रही है कि "मास्टर अब 1.0 पर है, कृपया इसे पुश करने वाले सभी के बजाय शाखा सुविधाओं को देखें"
मैंने ऊपर दिए गए नीतिगत दृष्टिकोण को छुआ। मास्टर के लिए नीति यह है कि यह निर्माण योग्य स्थिर रिलीज है। इसमें छोटे वृद्धिशील परिवर्तनों की जाँच करने का मतलब है कि आपके पास हर समय कुछ निर्माण योग्य स्थिर नहीं है । छोटे बदलावों में जाँच नहीं करना "बहुत सारे छोटे (लेकिन पूर्ण) चेकिन्स" के खिलाफ जाता है जो सबसे अच्छी नीति (और आसान शाखा द्वारा प्रोत्साहित) है।
भूमिका आधारित परिप्रेक्ष्य से, आपने मास्टर मेनलाइन, रिलीज़, रखरखाव और विकास भूमिकाओं के साथ शुरुआत की है , और फिर कुछ बिंदु सड़क के विकास और रखरखाव की भूमिका को शाखाओं तक ले जाते हैं। यह फिर से मास्टर में अनुमति दी गई है और जहां चीजों के रूप में योगदानकर्ताओं को भ्रमित कर सकते हैं में एक बदलाव का मतलब है। यह (थोड़ा) शाखा इतिहास को भ्रमित कर सकता है, बड़े कमिट को प्रोत्साहित कर सकता है जो विलय को समझने के लिए बड़ा और कठिन है।
शुरू से ही सरल और सुसंगत शाखाओं पर भूमिकाएँ और नीतियाँ।
यह "नीति परिवर्तन पर शाखा" शाखा पैटर्न में देखा जा सकता है । भूमिकाओं वाली प्रत्येक शाखा के विचार को एडवांस्ड एससीएम ब्रांचिंग स्ट्रैटेजीज में पढ़ा जा सकता है । ये दोनों बहुत अच्छे पढ़े लिखे हैं।
मुख्य रूप से दो स्थितियाँ हैं जहाँ आप आमतौर पर शाखाओं के साथ काम करना शुरू करते हैं:
जब आपको या आपकी टीम को एक नई सुविधा शुरू करनी होगी, जिसमें अगली रिलीज में शामिल नहीं होने की थोड़ी सी भी संभावना है (जो अब तक की पहली रिलीज हो सकती है), तो एक अलग फीचर शाखा में विकास शुरू करें
जब आपको नवीनतम रिलीज़ के लिए गंभीर बग्स के लिए फ़िक्सेस प्रदान करने हों, और आप एक नया बगफ़िक्स रिलीज़ बनाना चाहते हैं जिसमें केवल फ़िक्सेस हों, लेकिन कोई नया विकसित (और शायद अस्थिर) सुविधाएँ नहीं
इस तरह के फैसलों के लिए, मुझे लगता है कि "नई सुविधाओं" या "बगफिक्स" के संदर्भ में हमेशा यह सोचने में मददगार है कि आपके कार्यक्रम का पहला संकलन योग्य / रननीय संस्करण कहां है।
माइकल फेयर्स ने अपनी प्रसिद्ध पुस्तक में बदलने के चार कारणों को सूचीबद्ध किया है , लेकिन मैं "नई सुविधा शाखा" (गैर-कार्यात्मक सुविधा के लिए) के तहत "संसाधनों का अनुकूलन" करूंगा और "नई सुविधा शाखा" के तहत "डिजाइन में सुधार" को भी सबसे अधिक बार करूंगा। , क्योंकि IMHO एक को कभी भी डिज़ाइन में सुधार नहीं करना चाहिए जब यह किसी विशिष्ट सुविधा के कार्यान्वयन को आसान बनाने के उद्देश्य से नहीं किया जाता है।
यदि आप git-flow का अनुसरण करते हैं - और, काफी स्पष्ट रूप से, मुझे लगता है कि आप पागल हैं यदि आप Git का उपयोग करते हैं और उस ब्रांचिंग मॉडल का उपयोग नहीं करते हैं - तो आपको कभी भीmaster तब तक प्रतिबद्ध नहीं होना चाहिए जब तक आप वास्तव में सार्वजनिक रिलीज़ के लिए तैयार न हों।
आपकी पहली प्रतिबद्धता masterएक खाली भंडार होनी चाहिए। आपकी अगली प्रतिबद्धता शाखा या एक अस्थायी रिलीज शाखा masterसे मर्ज होने वाली होनी चाहिए develop, और यह स्थिर, परीक्षण और तैनाती के लिए तैयार होना चाहिए (यदि यह एक आवेदन है) या सार्वजनिक वितरण (यदि यह एक पुस्तकालय है)।
वहाँ रहे हैं Git के लिए अन्य शाखाओं में मॉडल, लेकिन उनमें से ज्यादातर बड़े केंद्रीकृत एससीएम मॉडल से प्राप्त कर रहे है और एक DVCS वातावरण में गंभीर समस्याओं को जन्म दे सकता है। आपको वास्तव में git-flow एक्सटेंशन का उपयोग करने की आवश्यकता नहीं है, और आपको उन सभी रिलीज़ / हॉटफ़िक्स / फ़ीचर शाखाओं की आवश्यकता नहीं है, लेकिन नंगे हड्डियों developऔर master, और अस्थिर कोड में जाता है develop।
master। याद रखें कि masterकुछ विशेष करने के लिए नहीं है, यह वहाँ होने की जरूरत नहीं है। जब तक आप एक रिलीज करना चाहते हैं तब तक आपके पास सिर्फ एक विकास शाखा हो सकती है।
नॉट फोर्ड ऑफ़ थॉटवर्क्स "मर्ज हेल" की समस्या से बचने के लिए ब्रांचिंग पर फ़ीचर टॉगल के उपयोग की वकालत करता है। उस मामले पर विचार करें जिसमें दो प्रोग्रामर मुख्य रूप से दैनिक रूप से मुख्य शाखा से विलय कर देते हैं और उनमें से एक सोम सप्ताह पर काफी बदलाव करता है और फिर शुरू होता है। अन्य प्रोग्रामर मर्ज नरक में बहुत अच्छी तरह से समाप्त हो सकता है। इस समस्या से बचने के लिए, फोर्ड केवल एक शाखा होने और इसे दैनिक रूप से करने के द्वारा "दर्द को आगे लाने" (एक प्रसिद्ध चुस्त विशेषता) की सिफारिश करता है। अतिरिक्त सुविधा को फीचर टॉगल के माध्यम से जोड़ा जाता है जो पूरी तरह से परीक्षण किए जाने तक सुविधा को अक्षम कर देता है।
यह कार्यप्रणाली एक ऐसे वातावरण में सबसे अच्छा काम करती प्रतीत होती है जो निरंतर वितरण को लागू करता है क्योंकि एक कमिट के साथ समस्याएं तुरंत पकड़ी जाएंगी।
इस सवाल के आखिरी जवाब के दो साल हो गए हैं और मुझे लगता है कि अब कहानी बदल गई है। मेरे लिए जवाब है "जब भी आप संस्करणों को ट्रैक करने के लिए स्रोत कोड नियंत्रण का उपयोग करते हैं।"
विस्तृत करने के लिए, इन दिनों स्रोत कोड नियंत्रण वाले प्रोजेक्ट संस्करणों को ट्रैक करना हमेशा काम नहीं करता है। (उदाहरण के लिए npm का उपयोग निर्भरता को प्रबंधित करने और '^' के साथ सिमेंटिक वर्जन को निर्दिष्ट करने के लिए) उस स्थिति में प्रोजेक्ट कलाकृतियों में हर बार बदलाव होता है, जरूरी नहीं कि सोर्स कोड में हर बार बदलाव हो। इस तरह की नई चुनौतियों से निपटने के लिए, कुछ टीमों ने ट्रैक प्रोजेक्ट संस्करणों के लिए पहले से ही आर्टिफिशियल कंट्रोल सिस्टम (उदाहरण के लिए। जेफ्रॉग आर्टिफैक्ट्री) में सहेजे गए 'कलाकृतियों' का चयन किया है।
जाहिर है जब आपके पास पहले से ही कलाकृतियों का संस्करण नियंत्रण होता है, तो आप एक GIT शाखा से 'उत्पादन कोड' नहीं खींचेंगे और उत्पादन के लिए निर्माण / परिनियोजित करेंगे, इसके बजाय आप तैनाती के लिए सीधे चलने योग्य संस्करणों के लिए कलाकृतियों के नियंत्रण प्रणाली से परामर्श करेंगे। ऐसे मामलों में 'रिलीज ब्रांच' की अवधारणा ने अचानक इसके अर्थ को ढीला कर दिया। और जब भी आपकी टीम रिलीज़ संस्करण के साथ git शाखा को संबद्ध नहीं करने का निर्णय लेती है, तो मास्टर के लिए सीधे प्रतिबद्ध / धक्का देना एक बार फिर एक ध्वनि विकल्प बन जाता है: यह डिफ़ॉल्ट शाखा के रूप में आता है जब भी रेपो का क्लोन होता है, इसलिए स्वचालित रूप से शब्दार्थ को व्यापक रूप से स्वीकार किया जाता है और अच्छी तरह से संप्रेषित किया जाता है। परिवर्तन। फिर भी, जैसा कि स्वीकृत उत्तर से पता चलता है, आपको संभवतः मास्टर सहित शाखाओं के लिए एक असाइन की गई भूमिका को जाना चाहिए, और उन शाखाओं का उपयोग केवल उन विशेष भूमिकाओं के लिए करना चाहिए।
अंतिम, मैं एक कदम आगे जा रहा हूं और केवल कुछ प्रमुख कोर कमिटर्स के साथ परियोजनाओं में विकास शाखा के रूप में मास्टर का उपयोग करने का सुझाव दे रहा हूं। मेरी टीम के लिए यही स्थिति है और संभवत: अधिकांश सूक्ष्म सेवाओं की दुकानों के लिए भी यही है। मास्टर पर कमिटिंग परिवर्तन प्रक्रिया के संचार को हटा देता है और संभावित रूप से कई मोर्चों पर काम करते समय 'मर्ज नर्क' से बचता है। इसके अलावा, मास्टर ब्रांच में कोड भी 'काम' करने के लिए नहीं है, स्वचालित निर्माण / परीक्षण प्रक्रिया आपको बताएगी कि क्या गलत हुआ और यह वैसे भी बहुत आसान है जो गिट इतिहास की जांच करें और लेखक से संपर्क करें जिसने बिल्ड / टेस्ट को तोड़ दिया है :-)
मैं एक कट्टरपंथी स्थिति लेने जा रहा हूं: हर विचार पर शाखा। पहले गिट शाखाओं में सस्ते होते हैं, एक शाखा की मुख्य लागत यह याद रखना है कि इसके लिए क्या है। मैं यह भी मानता हूं कि मास्टर के लिए पहला कमिट एक रिलीज का उम्मीदवार है। मैं अवधारणा शाखा के प्रमाण के साथ शुरुआत करने की सलाह देता हूं। जब आपने अपनी अवधारणा को साबित कर दिया है, तो आप इसे अपनी खाली devel शाखा के साथ मर्ज कर सकते हैं या अपनी पहली कोशिश कितनी अच्छी है, इसके आधार पर फिर से लिख सकते हैं। इस बिंदु से आप हर बग, सुविधा, अमूर्त, आदि के लिए devel से शाखा।