गिटहब फ्लो: जीथब वर्कफ्लो

गिट-फ्लो के मुद्दे

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

हालाँकि, git-flow में भी समस्याएँ हैं। मैंने अक्सर उन लोगों के विचारों को सुना है जिन्होंने इस तथ्य से शत्रुता व्यक्त की कि फीचर शाखाएं मास्टर के बजाय विकास से या हॉटफ़िक्स को संभालने के तरीके से प्रस्थान करती हैं, लेकिन ये समस्याएं अपेक्षाकृत छोटी हैं।

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

इन सभी समस्याओं को अधिक सरल वर्कफ़्लो का अनुसरण करके आसानी से दूर किया जा सकता है। हम गिटब में गिट-फ्लो का उपयोग नहीं करते हैं। Git के लिए एक सरल दृष्टिकोण के आधार पर हमारा वर्कफ़्लो (और हमेशा रहा है) आधारित है।

इसकी सादगी के कई फायदे हैं। सबसे पहले, लोगों के लिए इसे समझना आसान है, ताकि वे इसे तेज़ी से उपयोग करना शुरू कर दें, कम बार (या कभी भी नहीं) ऐसी गलतियां करते हैं जिनमें रोलबैक की आवश्यकता होती है। इसके अलावा, आपको प्रक्रिया का पालन करने में मदद करने के लिए एक आवरण स्क्रिप्ट की आवश्यकता नहीं होती है, इसलिए GUI (आदि) का उपयोग करने से समस्याएं नहीं होती हैं।

जीथब वर्कफ़्लो

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

नए उत्पादों के इस तरह के लगातार परिचय के कई फायदे हैं। यदि यह हर कुछ घंटों में होता है, तो बड़ी संख्या में प्रमुख कीड़े पैदा करना लगभग असंभव है। छोटी खामियां होती हैं, लेकिन उन्हें बहुत जल्दी से ठीक किया जा सकता है (और सुधार, बदले में लागू होते हैं)। आमतौर पर, आपको एक "हॉटफ़िक्स" बनाना होगा या किसी तरह सामान्य प्रक्रिया से विचलित करना होगा, लेकिन हमारे लिए यह सामान्य प्रक्रिया का हिस्सा बन जाता है: जीथब वर्कफ़्लो में एक हॉटफ़िक्स और एक छोटी सी सुविधा के बीच कोई अंतर नहीं है।

परिवर्तनों के निरंतर कार्यान्वयन का एक और लाभ किसी भी प्रकार की समस्याओं का जल्दी से जवाब देने की क्षमता है। हम सुरक्षा समस्याओं की रिपोर्ट पर प्रतिक्रिया दे सकते हैं या नई सुविधाओं के लिए छोटे (लेकिन दिलचस्प) अनुरोधों को निष्पादित कर सकते हैं - लेकिन एक सामान्य (या यहां तक ​​कि बड़े) आकार की विशेषता से संबंधित परिवर्तन करते समय एक ही प्रक्रिया काम करती है। प्रक्रिया समान है और यह बहुत सरल है।

हम इसे कैसे करते हैं

तो github वर्कफ़्लो क्या है?

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

वह पूरी वर्कफ़्लो है। यह बहुत सरल और उत्पादक है, यह काफी बड़े कार्य समूहों के लिए काम करता है - 35 लोग वर्तमान में गितुब में काम कर रहे हैं, जिनमें से शायद पंद्रह या बीस एक साथ एक ही परियोजना (github.com) पर काम कर रहे हैं । मुझे लगता है कि अधिकांश विकास टीमों (एक ही कोड के तर्क के साथ काम करने वाले समूह जो संघर्ष का कारण बन सकते हैं) का आकार समान है - या इससे कम। विशेष रूप से प्रगतिशील समूह जो तेजी से और सुसंगत कार्यान्वयन में संलग्न हैं।

तो, चलो क्रम में प्रत्येक चरण पर एक नज़र डालें।

मास्टर शाखा की सामग्री हमेशा तैनात रहती है।

सामान्य तौर पर, पूरे सिस्टम में यह एकमात्र सख्त नियम है। केवल एक शाखा है, जिसका हमेशा कुछ विशेष अर्थ होता है, और हमने इसे मास्टर कहा। हमारे लिए, इसका मतलब है कि इस शाखा के लिए कोड या तो उत्पादन पर लागू किया जाता है, या सबसे खराब स्थिति में, इसे कुछ घंटों में लागू किया जाएगा। इस शाखा को बहुत कम ही वापस लौटाया जाता है (कुछ काम रद्द करने के लिए): यदि कोई समस्या होती है, तो कमिट से परिवर्तन रद्द कर दिया जाता है या पूरी तरह से नए तरीके से समस्या को ठीक कर दिया जाता है, लेकिन शाखा स्वयं लगभग कभी पीछे नहीं जाती।

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

मास्टर शाखा से शाखाएं नई शाखाएं जिनके नाम उद्देश्य के अनुरूप हैं

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

और यह अच्छा है, क्योंकि जब हम जीथब पर शाखाओं की सूची के साथ पृष्ठ पर जाते हैं, तो यह देखना आसान है कि हमने हाल ही में किन शाखाओं पर काम किया है (और, लगभग, काम की मात्रा क्या थी)।



यह लगभग भविष्य की सुविधाओं की एक सूची की तरह है जो उनके वर्तमान राज्य के मोटे अनुमान के साथ है। यदि आप इस पृष्ठ का उपयोग नहीं करते हैं, तो आपको पता होना चाहिए कि इसकी शांत विशेषताएं हैं: यह आपको केवल उन्हीं शाखाओं को दिखाता है जिनमें काम किया गया था जो इस समय आपके द्वारा चुनी गई शाखाओं के लिए अद्वितीय है, और यहां तक ​​कि इस तरह से शाखाएं कि सबसे हाल की शाखाएं काम ऊपर से था। यदि मैं जिज्ञासा करना चाहता हूं, तो मैं "तुलना" बटन पर क्लिक कर सकता हूं और सटीक रूप से संयुक्त रूप से देख सकता हूं और इस शाखा के लिए अद्वितीय की सूची।

अब, जब मैं इसे लिखता हूं, तो हमारी 44 शाखाएँ हैं, जिनमें रिपॉजिटरी में असंबद्ध कोड हैं, लेकिन यह भी स्पष्ट है कि उनमें से केवल नौ या दस को ही पिछले सप्ताह में कोड प्राप्त हुआ था।

सर्वर पर नामांकित शाखा को लगातार भेजें

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

यह एक लैपटॉप या हार्ड ड्राइव की विफलता की स्थिति में एक सुरक्षा प्रतिलिपि बनाता है। यह डेवलपर्स के बीच सूचनाओं के निरंतर आदान-प्रदान का समर्थन करता है, और इससे भी महत्वपूर्ण बात। एक साधारण git fetch कमांड के साथ, आप उन TODOs की एक सूची प्राप्त कर सकते हैं जो हर कोई अभी काम कर रहा है।

$ git fetch remote: Counting objects: 3032, done. remote: Compressing objects: 100% (947/947), done. remote: Total 2672 (delta 1993), reused 2328 (delta 1689) Receiving objects: 100% (2672/2672), 16.45 MiB | 1.04 MiB/s, done. Resolving deltas: 100% (1993/1993), completed with 213 local objects. From github.com:github/github * [new branch] charlock-linguist -> origin/charlock-linguist * [new branch] enterprise-non-config -> origin/enterprise-non-config * [new branch] fi-signup -> origin/fi-signup 2647a42..4d6d2c2 git-http-server -> origin/git-http-server * [new branch] knyle-style-commits -> origin/knyle-style-commits 157d2b0..d33e00d master -> origin/master * [new branch] menu-behavior-act-i -> origin/menu-behavior-act-i ea1c5e2..dfd315a no-inline-js-config -> origin/no-inline-js-config * [new branch] svg-tests -> origin/svg-tests 87bb870..9da23f3 view-modes -> origin/view-modes * [new branch] wild-renaming -> origin/wild-renaming 

यह सभी को देखने की अनुमति देता है (जीथुब शाखा सूची पृष्ठ पर) जो बाकी सब पर काम कर रहा है - आप कोड का विश्लेषण कर सकते हैं और तय कर सकते हैं कि आप किसी चीज़ में डेवलपर की मदद करना चाहते हैं या नहीं ।

किसी भी समय एक मर्ज अनुरोध बनाएँ

GitHub में एक अद्भुत कोड समीक्षा प्रणाली है जिसे मर्ज अनुरोध कहा जाता है; मुझे डर है कि पर्याप्त डेवलपर्स इसके बारे में पूरी तरह से जागरूक नहीं हैं। कई लोग इसे खुले स्रोत कोड पर साधारण काम में उपयोग करते हैं: परियोजना को कांटा, कोड को अपडेट किया, परियोजना के मालिक को एक मर्ज अनुरोध भेजा। हालाँकि, इस प्रणाली का उपयोग आंतरिक कोड सत्यापन के साधन के रूप में भी किया जा सकता है, और इसलिए हम इसका उपयोग करते हैं।

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



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



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

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

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

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



जब शाखा पर काम पूरी तरह से और पूरी तरह से समाप्त हो जाता है और आपको लगता है कि यह कार्यान्वयन के लिए तैयार है, तो आप अगले चरण पर आगे बढ़ सकते हैं।

क्वेरी समीक्षा के बाद ही मर्ज करें

हम सीधे मास्टर शाखा में काम नहीं करते हैं , लेकिन हम इसे पूरा होने के तुरंत बाद नामित शाखा से काम को मर्ज नहीं करते हैं - पहले हम कंपनी के अन्य कर्मचारियों से अनुमोदन प्राप्त करने की कोशिश करते हैं। यह आमतौर पर "+1," या इमोजी , या टिप्पणी ": शिपिट:" का रूप लेता है , लेकिन हमें शाखा को देखने के लिए किसी और को लाने की आवश्यकता है।



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

समीक्षा के तुरंत बाद कार्यान्वयन

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

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



जैसा कि आप देख सकते हैं, छह अलग-अलग लोगों (एक समर्थन और एक डिजाइनर सहित) ने दिन में दो दर्जन से अधिक बार कोड लागू किया।

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

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

निष्कर्ष

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

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

उन समूहों के लिए जिनका काम कोड डिलीवरी के आसपास बनाया गया है, जो दैनिक रूप से उत्पादन को अपडेट करते हैं, लगातार परीक्षण करते हैं और सुविधाओं को लागू करते हैं, मैं एक सरल वर्कफ़्लो की सिफारिश करूंगा - जैसे कि GitHub Flow।