मैंने अभी गिट का उपयोग करना शुरू कर दिया है और गिट के साथ कुछ करने के लिए यह अपेक्षाकृत आसान है कि मुझे को गिट के साथ कुछ करने के लिए परेशानी हो रही है।गिट में शाखा कब करें?
उदाहरण के लिए, आमतौर पर कोई परियोजना प्रोजेक्ट कब करता है?
मैं वर्तमान प्रोजेक्ट के प्रत्येक संस्करण को ब्रांच करने की सोच रहा था और जब यह मास्टर के साथ इसे विलय कर रहा है - क्या यह सामान्य अभ्यास है?
मुझे यकीन है कि ऐसे लोग हैं जो मेरे द्वारा किए गए कार्यों से अलग होते हैं।
मुझे यकीन नहीं है कि वर्तमान प्रोजेक्ट के प्रत्येक संस्करण को ब्रांच करके आपका क्या मतलब है।
वैसे भी, गिट सलाह देता है कि आप 'विषय शाखा' बनाएं। 'विषय शाखा' से, इसका मतलब है कि जब आप किसी सुविधा/बग पर काम कर रहे हों तो आप एक शाखा बनाते हैं। मान लीजिए कि मैं jQueryUI पर काम कर रहा हूं और मुझे jQuery कैलेंडर में एक सुविधा जोड़ने के लिए कहा गया है जो उपयोगकर्ता को उन तारीखों को निर्दिष्ट करने की अनुमति देता है जो चयन योग्य नहीं हैं।
यदि मैं मास्टर नाम की शाखा में हूं, तो मैं 'निर्दिष्ट दिनांक एक्सक्लूस' शाखा नामक एक स्थानीय शाखा तैयार करूंगा और अपना परिवर्तन करना शुरू कर दूंगा। इस सुविधा से संबंधित कोई भी और सभी कोड इस शाखा में जाएगा।
master
|
|
|___ SpecifyDateExclusion
जबकि मैं इस सुविधा पर काम कर रहा हूं, एक बग रिपोर्ट में आता है कि ओपेरा 10 में कैलेंडर टूट गया है और इस बग को अब ठीक करने की आवश्यकता है। मैं अपनी मास्टर शाखा में वापस जाता हूं और Opera10BugFix नाम की एक और शाखा बनाता हूं और इसमें बग फिक्स करना शुरू करता हूं।
master
|
|
|___ SpecifyDateExclusion
|
|
|___ Opera10BugFix
बहुत जल्द ही, आप की तरह
master
|
|
|___ SpecifyDateExclusion
|
|___ Feature1
|
|___ Feature2
|
|___ Feature3
|
|___ Opera10BugFix
|
|___ BugFix1
|
|___ BugFix2
लाभ आप पूछ सकते हैं क्या शाखाओं हो सकता है?
लाभ मेरी रिलीज तैयार करते समय मुझे लचीलापन देता है। मान लें कि मेरी अगली रिलीज मुख्य रूप से बग फिक्स के बारे में है।
मैं मास्टर से 'इंटरिमबगफिक्स' नामक एक नई शाखा तैयार करूंगा और अपनी सभी बग फिक्स शाखाओं को विलय कर दूंगा।
अगर मैं बग/फीचर रिलीज का मिश्रण बनाना चाहता हूं, तो मैं मास्टर से 'नेक्स्टवर्सियन' नाम की एक शाखा तैयार करूंगा और अपनी फीचर/बग फिक्स शाखाओं को मर्ज कर दूंगा।
गिट इन शाखाओं को प्रबंधित करने के तरीके के बारे में बेहद शक्तिशाली है और यदि आप कुछ कल्पना कर सकते हैं, तो गिट आपको ऐसा करने देगा।
आपकी "शाखा रणनीति" के आधार पर इसके कई जवाब हैं। 2 सबसे सरल (मेरे अनुभव में) कार्य/फीचर शाखाएं और रिलीज शाखाएं हैं। जो आप उपयोग करेंगे, वह इस बात पर निर्भर करेगा कि आपके रिलीज चक्र अन्य चीजों के साथ कैसे काम करता है।
यदि आप निरंतर एकीकृत और जारी कर रहे हैं तो कार्य/फीचर शाखाएं समझ में आती हैं, क्योंकि वे अपेक्षाकृत स्थिर स्थिति में "मास्टर" (अन्य वीसीएस में ट्रंक) छोड़ देते हैं, जिससे रिलीज़ आसान हो जाता है। लेकिन यदि आपके पास अधिक संरचित रिलीज चक्र है, तो शायद शाखाएं रिलीज हो जाएंगी क्योंकि उन्हें प्रत्येक रिलीज में जो जोड़ा जाता है, उसे अधिक सावधानीपूर्वक परिभाषित करने के लिए उपयोग किया जा सकता है। बेशक, एक संकर रणनीति भी व्यवहार्य है।
मैं आमतौर पर कार्य/फीचर शाखाओं का उपयोग करता हूं, इसलिए प्रत्येक बग या फीचर अनुरोध ब्रांच किया जाता है। फिर काम किया जाता है और, जब पूरा हो जाता है, तो मास्टर में वापस विलय हो जाता है।
गिट के बारे में सबसे अच्छी बात यह है कि यह आपके लिए किसी भी फैसले को मजबूर नहीं करता है। गिट के बारे में बुरी बात यह है कि यह आपके लिए किसी भी फैसले को मजबूर नहीं करता है।
आपका वर्कफ़्लो पूरी तरह से आपके ऊपर है। क्या आप सहयोग करने का इरादा रखते हैं, या आप स्वतंत्र रूप से विकास कर रहे हैं? क्या आपके पास रिलीज़ के बीच एक छोटा या लंबा लीड टाइम है? ये बाधाएं उपयुक्त वर्कफ़्लो को परिभाषित करने में मदद कर सकती हैं।
मैं दो सप्ताह के पुनरावृत्ति चक्र के साथ 4 डेवलपर्स की एक छोटी टीम में काम करता हूं। चक्र की शुरुआत में हम एक दायरे पर सहमत हैं और मास्टर के खिलाफ विकसित होते हैं। किसी भी चीज जिसे हम दो सप्ताह से अधिक होने की उम्मीद करते हैं, एक शाखा में स्थानांतरित हो जाता है (या जीवन शुरू होता है) (यह अक्सर नहीं होता है, हमारा दायरा तंग होता है)।
दो सप्ताह चक्र के अंत में, हम अपना क्यूए, टैग और रिलीज करते हैं। अगले चक्र की शुरुआत से, उन अन्य शाखाओं को वापस मास्टर में विलय कर दिया जाता है।
यदि आपको रिलीज पैच करने की आवश्यकता है, तो हम एक शाखा, प्रतिबद्धता, क्यूए, टैग और रिलीज बनाते हैं।
किसी भी प्रयोगात्मक के लिए, हम आम तौर पर एक नई शाखा बनायेंगे और इसे तब तक मास्टर से अलग रखें जब तक कि इसे विलय करने या त्यागने के लिए उपयुक्त न हो।
सारांश में, हमारी टीम शाखाओं जब:
हमारे कार्यप्रवाह बहुत केंद्रीकृत है, और शायद कई गिट उपयोगकर्ताओं के। न तो सही या गलत है, यह सिर्फ सबसे उपयुक्त क्या चुनने के बारे में है।
"मास्टर के खिलाफ विकसित करें" - क्या इसका मतलब यह है कि आप मास्टर शाखा का उपयोग करके विकसित होते हैं? – LDK
यह सही है। –
यह बहुत महत्वपूर्ण है: गिट में वर्जन कंट्रोल वर्कफ़्लो नहीं है। इसके बजाय, यह एक संस्करण नियंत्रण वर्कफ़्लो निर्माण किट है। और बस एक लेगो निर्माण किट के साथ, सबकुछ एक साथ रखना कठिन और कठिन, उबाऊ काम का * बहुत * है, लेकिन परिणाम * कमाल * होने वाला है, क्योंकि यह * तुम्हारा * है, * आपने * इसे अपने साथ बनाया है हाथ, और यह बिल्कुल आपकी जरूरतों के अनुरूप बनाया गया है। खूब कहा है! –
वेब अनुप्रयोग विकास में, हम ऐसा करते हैं:
हम एक प्राचीन शाखा "उत्पादन" कहा जाता है बनाए रखें। इसमें कोड शामिल है जो लाइव वेबसाइटों पर मौजूद है।
कार्य शाखाओं में होने वाले किसी भी बदलाव में। तो आप एक शाखा कार्य -13 9 23-ऐड-फीचर-एक्स देख सकते हैं। ये शाखा उत्पादन शाखा से बनाई गई हैं और उत्पादन शाखा को उत्पादन में विलय करने से पहले उन्हें में विलय किया जाना चाहिए (इसलिए यह हमेशा एक साफ तेज़ आगे, कोई संभावित संघर्ष नहीं होता है)।
हर कोई समय-समय पर "उत्पादन" शाखा को अपनी कार्य शाखाओं में अद्यतित रहने के लिए विलय करता है।
संदेह में, शाखा। शाखाएं सस्ते हैं, और नई शाखाओं की जानकारी आसानी से पुरानी शाखाओं में स्थानांतरित की जा सकती है।जब एक शाखा ने अपनी उपयोगिता को पार कर लिया है, तो इसे आसानी से मारा जा सकता है।
"मास्टर वर्क को वर्क इन प्रोग्रेस (डब्ल्यूआईपी) नहीं बनाकर साफ करें" मुझे यह विचार पसंद है। – LDK