Git
वर्कफ़्लोज़ के प्रकारों का विश्लेषण करना

टिप्पणियों

Gitflow Workflow

मूल रूप से विंसेंट ड्रिसेन द्वारा प्रस्तावित, Gitflow git और कई पूर्व-परिभाषित शाखाओं का उपयोग करके एक विकास वर्कफ़्लो है। इसे फ़ीचर ब्रांच वर्कफ़्लो के विशेष मामले के रूप में देखा जा सकता है।

इस एक का विचार विकास में विशिष्ट भागों के लिए अलग-अलग शाखाएं हैं:

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

इस मॉडल का एक दृश्य प्रतिनिधित्व:

इस मॉडल का मूल प्रतिनिधित्व:

Forking वर्कफ़्लो

इस प्रकार के वर्कफ़्लो इस विषय पर उल्लिखित अन्य की तुलना में मौलिक रूप से भिन्न हैं। इसके बजाय एक केंद्रीकृत रेपो होने कि सभी डेवलपर्स के लिए उपयोग कर सकते है की, हर डेवलपर उसका / उसकी खुद रेपो कि मुख्य रेपो से अलग किया जाता है। इसका लाभ यह है कि डेवलपर्स एक साझा रेपो के बजाय अपने स्वयं के रेपो में पोस्ट कर सकते हैं और एक अनुरक्षक जब भी उचित हो, कांटे वाले रिपोज से मूल में परिवर्तन को एकीकृत कर सकता है।

इस वर्कफ़्लो का एक दृश्य प्रतिनिधित्व इस प्रकार है:

केंद्रीकृत वर्कफ़्लो

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

इस मॉडल का दृश्य प्रतिनिधित्व:

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

यही कारण है कि लिनस टॉर्वाल्ड्स ने Git को CVCS के रूप में नहीं बनाया, बल्कि मर्क्यूरियल के समान एक DVCS , या वितरित संस्करण नियंत्रण प्रणाली के रूप में बनाया । चीजों को करने के इस नए तरीके का लाभ इस पृष्ठ पर अन्य उदाहरणों में प्रदर्शित लचीलापन है।

फ़ीचर ब्रांच वर्कफ़्लो

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

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

एटलसियन ट्यूटोरियल के आधार पर।

गिटहब फ्लो

कई ओपन सोर्स प्रोजेक्ट्स में लोकप्रिय हैं, लेकिन न केवल।

किसी विशिष्ट स्थान की मास्टर शाखा (Github, Gitlab, Bitbucket, स्थानीय सर्वर) में नवीनतम shippable संस्करण है। नई सुविधा / बग फिक्स / वास्तु परिवर्तन के लिए प्रत्येक डेवलपर एक शाखा बनाता है।

परिवर्तन उस शाखा पर होते हैं और एक पुल अनुरोध, कोड समीक्षा, आदि में चर्चा की जा सकती है एक बार स्वीकार किए जाने के बाद वे मास्टर शाखा में विलय हो जाते हैं।

स्कॉट चाकोन द्वारा पूर्ण प्रवाह:

• मास्टर शाखा में कुछ भी तैनात है
• कुछ नया काम करने के लिए, एक वर्णनात्मक रूप से नामित शाखा ऑफ मास्टर बनाएं (जैसे: new-oauth2-scopes)
• उस शाखा के लिए स्थानीय स्तर पर और नियमित रूप से सर्वर पर उसी नामित शाखा में अपना काम करें
• जब आपको प्रतिक्रिया या सहायता की आवश्यकता होती है, या आपको लगता है कि शाखा विलय के लिए तैयार है, तो एक पुल अनुरोध खोलें
• किसी और व्यक्ति ने फीचर पर समीक्षा और हस्ताक्षर करने के बाद, आप इसे मास्टर में विलय कर सकते हैं
• एक बार जब यह विलय हो जाता है और 'मास्टर' पर धकेल दिया जाता है, तो आपको तुरंत तैनात करना चाहिए

मूल रूप से स्कॉट चाकोन की निजी वेब साइट पर प्रस्तुत किया गया।

GitHub फ्लो संदर्भ की छवि शिष्टाचार