रिपॉजिटरी के साथ काम का संगठन

लक्ष्य:

- नई परियोजना कार्यक्षमता के निरंतर कार्यान्वयन का संगठन

- परियोजना का समर्थन करने की प्रक्रिया में बग को ठीक करने के लिए एक संबंधित प्रणाली

- समग्र रूप से परियोजना की गुणवत्ता में सुधार

- परियोजना के अलग-अलग हिस्सों का परमाणु विकास (मॉड्यूल / कार्य)



ऊपर वर्णित लक्ष्यों को प्राप्त करने के लिए, निम्नलिखित शाखा संरचना को व्यवस्थित करना आवश्यक है:

रिहाई

हॉटफ़िक्स (वैकल्पिक)

परीक्षण

फ़िक्सेस (वैकल्पिक)

चूक

डेवलपर्स शाखाओं (सशर्त नाम)



1. जारी

इस शाखा में परियोजना की वर्तमान कार्यशील प्रतिलिपि शामिल है, जिसमें से परियोजना को उत्पादन सर्वर पर रोल आउट किया जाता है।



2. हॉटफ़िक्स

यह कोई रहस्य नहीं है कि परियोजना के उत्पादन सर्वर में रोल आउट होने के बाद, अप्रत्याशित कीड़े दिखाई दे सकते हैं,

सबसे अधिक बार ये छोटी-मोटी खामियां हैं, यदि बग वास्तव में छोटा है, तो सीधे संपादन की अनुमति है

रिलीज़ शाखा में, यदि संपादन तुच्छ नहीं है, तो आपको यह करना चाहिए:

रिलीज़ शाखा से एक शाखा बनाएँ (हॉटफिक्सेस_ को शाखा नाम में एक उपसर्ग के रूप में मौजूद होना चाहिए, उदाहरण के लिए: हॉटफिक्सेस -सीपीएस)

b बग को ठीक करना।

सी रिलीज शाखा पर स्विच करें

d रिलीज शाखा में मिलता है, शाखा से सभी फिक्स्ड बग के साथ संपादन करता है।

ई परीक्षण (यदि संभव हो तो)

f रिलीज ब्रांच से प्रोडक्शन सर्वर को अपडेट करें

जी 1 द्वारा टैग संस्करण का मूल्य बढ़ाएं (उदाहरण के लिए: यह 1.0.0 था, यह 1.0.1 हो गया)



3 परीक्षण

इस शाखा में नई सुविधाएँ शामिल हैं जिन्हें परियोजना के अगले संस्करण में शामिल किया जाना चाहिए।

इस शाखा के तहत एक अलग वातावरण होना चाहिए, जितना कि सेना के करीब हो,

इस शाखा में जो कोड होता है उसका सक्रिय परीक्षण किया जाता है।

किसी भी बग की पहचान करते समय, इस शाखा के कोड में, हम सुधार करते हैं जब तक कि हम बग रिपोर्ट से पूरी तरह से छुटकारा नहीं पा लेते।



परीक्षण के अंत में, और बग को ठीक करते हुए, हम निम्नलिखित उत्पादन करते हैं:

रिलीज़ शाखा पर स्विच करें

b परीक्षण शाखा से सभी शाखाएँ रिलीज़ शाखा में प्राप्त करें

सी परीक्षण (यदि संभव हो तो)

d रिलीज ब्रांच से प्रोडक्शन सर्वर को अपडेट करें



4 फिक्स

कार्य प्रक्रिया खंड 2 में वर्णित प्रक्रिया के समान है (उपयोग का एक उदाहरण "कार्य प्रक्रिया" अनुभाग में वर्णित है)



5 डिफ़ॉल्ट

इस शाखा में परियोजना की विशेषताएं हैं, जो परीक्षण चरण में प्रवेश करने के लिए तैयार है। एक शाखा के लिए पूरी तरह से मौजूद है

ताकि डेवलपर्स परियोजना के अनुसार एक पूरे के रूप में कार्यक्षमता का परीक्षण कर सकें (कई डेवलपर्स के मॉड्यूल की बातचीत)



6 डेवलपर्स शाखाएँ

वास्तव में, यह एक शाखा नहीं है, यह सभी शाखाओं का सामान्य नाम है जो नई कार्यक्षमता हैं।



कार्य प्रक्रिया:

जब नई सुविधाओं का एक सेट तैयार होता है (और कम से कम उनकी कार्यक्षमता के प्रत्येक प्रोग्रामर द्वारा परीक्षण किया जाता है),

और प्रबंधक ने नई कार्यक्षमता को रोल करने के लिए हरी बत्ती दी, फिर सुविधा डिफ़ॉल्ट शाखा में विलीन हो गई

(प्रोग्रामर देखता है कि उसकी कार्यक्षमता अन्य मॉड्यूल के साथ कैसे काम करती है), अगर सब कुछ ठीक है,

फिर डिफ़ॉल्ट शाखा से परीक्षण शाखा में सुविधाओं को मर्ज करें। इस बिंदु पर, वर्तमान रिलीज़ में नई सुविधाओं की उपस्थिति वांछनीय नहीं है।

कोड जो परीक्षण शाखा में है, का परीक्षण किया जाता है, बग फिक्स करता है

(फ़िक्सेसिंग बग्स उसी क्रम में होती हैं जैसे कि हॉटफ़िक्स के मामले में, केवल महत्वपूर्ण बग्स को ठीक करने के लिए

शाखा का नामकरण केवल fix_ पर लागू किया जाता है, उदा। fix_calls)

मुख्य क्यूए के बाद, पुष्टि की गई कि कोड उत्पादन सर्वर पर काम करने के लिए तैयार है, परीक्षण से रिलीज में परिवर्तन को मर्ज करें।

हम वर्तमान संस्करण को टैग करते हैं जो उत्पादन में मिला है। (उदाहरण के लिए: 1.0.640 1.1.0 बन गया)