गिटहब फ्लो और गिटलैब फ्लो के बीच क्या अंतर है?

Question

हाल ही में मुझे जीआईटी में एक वर्कफ़्लो की तीन अवधारणाएं मिली हैं: गिटफ्लो, गिटहब फ्लो और गिटलैब फ्लो। मैंने इसके बारे में अच्छा लेख पढ़ा है (https://docs.gitlab.com/ee/workflow/gitlab_flow.html) लेकिन मुझे गिटलैब प्रवाह बहुत अच्छी तरह से समझ में नहीं आता है। शायद क्योंकि मैं मूल निवासी नहीं हूं :)

संक्षेप में।

गिटफ्लो (https://docs.gitlab.com/ee/workflow/gitdashflow.png)।

हमारे पास एक उत्पादन शाखा के रूप में एक मास्टर शाखा है। इसके अलावा हमारे पास एक विकास शाखा है जहां हर डेवलपर अपनी विशेषताओं को विलीन करता है। कभी-कभी हम उत्पादन में हमारी सुविधाओं को तैनात करने के लिए एक रिलीज शाखा बनाते हैं। अगर हमारे पास रिलीज शाखा में एक बग है, तो इसे ठीक करें और विकास शाखा में बदलाव खींचें। अगर हमारे पास उत्पादन में एक महत्वपूर्ण बग है, तो नई हॉटफिक्स-शाखा बनाएं, बग ठीक करें और उत्पादन (मास्टर) के साथ शाखा मर्ज करें और शाखाएं विकसित करें।

यह दृष्टिकोण बहुत अच्छा है अगर हम शायद ही कभी हमारे काम के परिणाम दिखाते हैं। (शायद 2 सप्ताह प्रति बार एक समय)।

गिटहब फ्लो (https://docs.gitlab.com/ee/workflow/github_flow.png)।

हमारे पास एक उत्पादन शाखा के रूप में एक मास्टर शाखा है। और हम (डेवलपर्स के रूप में) केवल नई सुविधाओं को जोड़ने या बग फिक्स करने और उत्पादन (मास्टर) शाखा के साथ मर्ज करने के लिए शाखाएं बना सकते हैं। यह बहुत आसान लगता है। यह दृष्टिकोण चरम प्रोग्रामिंग के लिए फिट बैठता है जहां उत्पादन शाखा एक दिन में कई बार तैनात की जाती है।

गिटलैब प्रवाह (https://docs.gitlab.com/ee/workflow/production_branch.png, https://docs.gitlab.com/ee/workflow/environment_branches.png, https://docs.gitlab.com/ee/workflow/release_branches.png)।

मैंने पूर्व-उत्पादन, एक उत्पादन, एक रिलीज (स्थिर) शाखा और एक स्टेजिंग वातावरण, एक पूर्व उत्पादन वातावरण, एक उत्पादन वातावरण जैसे नए शब्द देखा है। उनके बीच उनके संबंध क्या हैं?

मैं इसे इस तरह समझता हूं: यदि हमें एक नई सुविधा जोड़ने की आवश्यकता है तो हम मास्टर शाखा से प्री-प्रोडक्शन शाखा तैनात करते हैं। जब हमने इस सुविधा को पूरा कर लिया है तो हम प्री-प्रोडक्शन शाखा से उत्पादन शाखा तैनात करते हैं। एक पूर्व उत्पादन शाखा मध्यवर्ती चरण है। और फिर मास्टर शाखा उत्पादन शाखा से सभी परिवर्तन खींचती है।

यदि हम प्रत्येक अलग सुविधा देखना चाहते हैं तो दृष्टिकोण अच्छा है। हम सिर्फ उस शाखा में चेकआउट करते हैं जिसे हमें चाहिए और देखें।

लेकिन अगर हमें अपना काम दिखाना है तो हम जितनी देर हो सके टैग के साथ रिलीज शाखा बनाते हैं। यदि बाद में हम मास्टर शाखा में बग ठीक करते हैं तो हमें चेरी की आवश्यकता होती है-उन्हें अंतिम रिलीज शाखा में ले जाएं। अंत में हमारे पास टैग के साथ रिलीज शाखा है जो हमें संस्करणों के बीच स्थानांतरित करने में मदद कर सकती है।

क्या मेरी दृष्टि सही है? पुल और चेरी-पिक के बीच क्या अंतर है?

Answer 1

गिटलैब प्रवाहmaster और feature शाखाओं का भी उपयोग करने का प्रस्ताव करता है। एक बार सुविधा पूरी होने के बाद हम इसे master शाखा में विलय कर दें। यह भाग गिटहब फ्लो जैसा दिखता है।

तब मेरी समझ यह है कि वे इसे एसएएएस ऐप या मोबाइल ऐप (जिसे दुनिया में रिलीज़ किया जा सकता है) के आधार पर इसे करने के तरीके पर 2 विकल्प देते हैं।

यदि यह SAAS ऐप है तो हम पर्यावरण शाखाओं का उपयोग करते हैं उदा। pre-production और production। जब हम अपने आवेदन को तैनात करने के लिए तैयार हों तो इन शाखाओं को master से बनाया गया है। प्रति माह विभिन्न शाखाएं होने से हम इन शाखाओं में किए गए कार्यों पर स्वचालित रूप से तैनात करने के लिए सीआई/सीडी उपकरण स्थापित करने की अनुमति देते हैं। यदि कोई महत्वपूर्ण समस्या है तो हम इसे feature या master शाखा में ठीक करें और फिर इसे environment शाखाओं में विलय करें।

दुनिया के लिए जारी किए जा सकने वाले अनुप्रयोगों के लिए (जैसे मोबाइल या डेस्कटॉप ऐप्स) मेरी समझ यह है कि वे पर्यावरण शाखाओं की बजाय release शाखाओं का उपयोग करके विभिन्न मॉडल का उपयोग करने का प्रस्ताव करते हैं। हम अभी भी feature शाखाओं में सभी काम करते हैं और उन्हें पूरा होने पर master शाखा में वापस विलय करते हैं। फिर जब हम सुनिश्चित करते हैं कि master शाखा पर्याप्त स्थिर है यानी हम पहले से ही सभी परीक्षण और बग फिक्सिंग कर चुके हैं, हम release शाखा बनाते हैं और हमारे सॉफ़्टवेयर को छोड़ देते हैं। यदि कोई महत्वपूर्ण समस्या है तो हम इसे पहले master शाखा में ठीक करें और चेरी-release शाखा में एक फिक्स चुनें।

Answer 2

इस पोस्ट को उठाए जाने के बाद से यह एक साल हो गया है, लेकिन भविष्य के पाठकों पर विचार करने और तथ्य की बातों में थोड़ा बदलाव आया है, मुझे लगता है कि यह ताज़ा करने योग्य है।

GitHub फ्लोoriginally depicted by Scott Chacon in 2011 के रूप में एक बार एक feature branch पर समीक्षा की प्रत्येक परिवर्तन ग्रहण किया और master में विलय कर दिया तुरंत उत्पादन के लिए तैनात किया जाना चाहिए। इस समय काम किया और केवल GitHub प्रवाह नियम है, जो गुरु शाखा में कुछ भी है परिनियोजन योग्य, it was quickly discovered इसी क्रम में उत्पादन करने के लिए उत्पादन कोड काम वास्तविक तैनाती master जाना जाता के एक सच्चे रिकॉर्ड रखने के लिए पुष्टि करते हुए करना चाहिए feature branchसेmaster में विलय होने से पहले होता है। feature branch से तैनाती पूरी तरह से समझ में आता है क्योंकि किसी भी मुद्दे के उत्पादन के मामले में तत्काल master को तैनात करके वापस किया जा सकता है। कृपया गिटहब फ्लो पर a short visual introduction पर एक नज़र डालें।

GitLab फ्लो कि आगे की प्रक्रिया का मानकीकरण करने का लक्ष्य guidelines and best practices का एक सेट के साथ GitHub प्रवाह के लिए एक विस्तार की तरह है।

1. Production branch
2. Environment branches: uat, pre-production, production
3. Release branches: 1-5-stable, 1-6-stable एक तरफ master शाखा और सुविधा शाखाओं (GitHub प्रवाह के रूप में ही) तैनात करने के लिए यह शाखाओं के तीन अन्य प्रकार का परिचय तैयार को बढ़ावा देने से

मुझे विश्वास है कि नाम और उदाहरण स्वयं वर्णनात्मक हैं, इस प्रकार मैं फर्ट को विस्तारित नहीं करूंगा उसके।