गोंधळाशिवाय टीमवर्क: Git मधील शाखा धोरणे समजून घेणे

परिचय

सॉफ्टवेअर डेव्हलपमेंटमधील आवृत्ती नियंत्रण प्रणालींसाठी गिट हे वास्तविक उद्योग मानक बनले आहे. गिट म्हणजे काय आणि सुरुवात कशी करावी याबद्दल तुम्ही प्रथम माझा लेख वाचा. तुम्ही ते वाचले आहे का? छान, चला जाऊया! हे आवडले किंवा नाही, लिनस टोवाल्ड्सने तयार केलेले हे साधन निवृत्त होणार नाही. म्हणून, वितरीत कार्यसंघ Git सोबत कसे कार्य करतात आणि यासाठी त्यांनी कोणती शाखा धोरण निवडले पाहिजे याबद्दल बोलण्यात अर्थ आहे. हा काही अवास्तव प्रश्न नाही. पूर्वी एकत्र काम न केलेल्या नवीन विकास कार्यसंघाचे एकत्रीकरण करताना, ब्रँचिंग स्ट्रॅटेजी ही बर्‍याचदा ठरविण्याच्या पहिल्या गोष्टींपैकी एक असते. आणि एक रणनीती दुसर्‍यापेक्षा चांगली आहे हे सिद्ध करण्यासाठी काही लोक तोंडाला फेस आणतील. म्हणून, मला त्यांच्याबद्दल काही सामान्य माहिती सांगायची आहे.

शाखा धोरण आवश्यक आहे का?

ते खरोखर आवश्यक आहेत. अत्यंत आवश्यक. कारण जर संघ एखाद्या गोष्टीवर सहमत नसेल, तर प्रत्येक कार्यसंघ सदस्य त्याला किंवा तिला पाहिजे ते करेल:

• कोणत्याही शाखेत काम करतो
• अनियंत्रित इतर शाखांमध्ये विलीन करणे
• काही शाखा हटवत आहे
• नवीन तयार करणे
• आणि म्हणून प्रत्येक कार्यसंघ सदस्य अनियंत्रित प्रवाहात कार्य करेल.

म्हणूनच आमच्याकडे खाली विचार करण्यासाठी तीन धोरणे आहेत. चल जाऊया!

GitHub प्रवाह

ही शाखाबद्ध रणनीती, विचित्रपणे, GitHub वर प्राधान्य दिले जाते :) हे नियमांच्या संचासह येते :

1. मास्टर ब्रँचमधील कोड मोडू नये. ते कोणत्याही वेळी तैनात करण्यासाठी तयार असले पाहिजे. म्हणजेच, तुम्ही तेथे कोड टाकू नये जो तुम्हाला प्रकल्प तयार करण्यापासून आणि सर्व्हरवर तैनात करण्यापासून प्रतिबंधित करेल.
2. जेव्हा तुम्ही नवीन कार्यक्षमतेवर काम करण्याची योजना आखता, तेव्हा तुम्हाला मास्टर ब्रँचवर आधारित एक नवीन वैशिष्ट्य शाखा तयार करणे आणि त्याला अर्थपूर्ण नाव देणे आवश्यक आहे. तुमचा कोड स्थानिक पातळीवर पाठवा आणि तुमचे बदल नियमितपणे रिमोट रिपॉझिटरीमध्ये त्याच शाखेत करा.
3. जेव्हा तुम्हाला असे वाटते की काम तयार आहे आणि ते मास्टर ब्रँचमध्ये विलीन केले जाऊ शकते (किंवा तुम्हाला खात्री नसल्यास, परंतु काम केल्याबद्दल अभिप्राय मिळवायचा असेल तर) पुल विनंती (तुम्ही पुल विनंत्यांबद्दल येथे वाचू शकता) उघडा .
4. पुल रिक्वेस्टमधील नवीन फीचर मंजूर झाल्यानंतर, ते मास्टर ब्रँचमध्ये विलीन केले जाऊ शकते.
5. जेव्हा बदल मास्टर शाखेत विलीन केले जातात, तेव्हा ते त्वरित सर्व्हरवर तैनात केले जावे.

GitHub Flow नुसार, तुम्ही नवीन गोष्टीवर काम सुरू करण्यापूर्वी, ते फिक्स असो किंवा नवीन फीचर, तुम्हाला मास्टरवर आधारित नवीन शाखा तयार करणे आणि त्याला योग्य नाव देणे आवश्यक आहे. पुढे, अंमलबजावणीचे काम सुरू होते. तुम्ही त्याच नावाने रिमोट सर्व्हरवर सतत कमिट सबमिट करा. जेव्हा आपण असा निष्कर्ष काढता की सर्वकाही तयार आहे, तेव्हा आपल्याला मुख्य शाखेकडे पुल विनंती तयार करण्याची आवश्यकता आहे. मग किमान एक, किंवा अजून चांगले, दोन लोकांनी "मंजूर करा" वर क्लिक करण्यापूर्वी हा कोड पहावा. सहसा, प्रकल्पाच्या टीम लीडने आणि दुसर्‍या व्यक्तीने निश्चितपणे पहावे. मग आपण पुल विनंती पूर्ण करू शकता. गिटहब फ्लो प्रकल्पांमध्ये सतत वितरण (सीडी) चालविण्यासाठी देखील ओळखले जाते . याचे कारण असे की जेव्हा बदल मास्टर शाखेत जातात, तेव्हा ते त्वरित सर्व्हरवर तैनात केले जावेत.

GitFlow

मागील रणनीती (GitHub Flow) त्याच्या मुळाशी फारशी क्लिष्ट नाही. दोन प्रकारच्या शाखा आहेत: मास्टर आणि वैशिष्ट्य शाखा. पण GitFlow अधिक गंभीर आहे. किमान, वरील चित्राने हे स्पष्ट केले पाहिजे :) मग ही रणनीती कशी कार्य करते? सर्वसाधारणपणे, GitFlow मध्ये दोन सतत शाखा आणि अनेक प्रकारच्या तात्पुरत्या शाखा असतात. गिटहब फ्लोच्या संदर्भात, मुख्य शाखा कायम आहे आणि इतर तात्पुरत्या आहेत. सतत शाखा

• मास्तर: या शाखेला कोणीही हात लावू नये किंवा ढकलू नये. या रणनीतीमध्ये, मास्टर नवीनतम स्थिर आवृत्तीचे प्रतिनिधित्व करतो, जी उत्पादनात वापरली जाते (म्हणजेच, वास्तविक सर्व्हरवर)
• विकास: विकास शाखा. ते अस्थिर असू शकते.

तीन सहाय्यक तात्पुरत्या शाखांचा वापर करून विकास होतो :

1. वैशिष्ट्य शाखा — नवीन कार्यक्षमता विकसित करण्यासाठी.
2. रिलीझ शाखा - प्रकल्पाच्या नवीन आवृत्तीच्या प्रकाशनाच्या तयारीसाठी.
3. हॉटफिक्स शाखा — वास्तविक सर्व्हरवर वास्तविक वापरकर्त्यांद्वारे आढळलेल्या बगचे त्वरित निराकरण करण्यासाठी.

वैशिष्ट्य शाखा

नवीन कार्यक्षमतेसाठी विकासकांनी वैशिष्ट्य शाखा तयार केल्या आहेत. ते नेहमी विकास शाखेवर आधारित तयार केले पाहिजेत. नवीन कार्यक्षमतेवर काम पूर्ण केल्यानंतर, तुम्हाला विकास शाखेकडे पुल विनंती तयार करणे आवश्यक आहे. स्पष्टपणे, मोठ्या संघांमध्ये एका वेळी एकापेक्षा जास्त वैशिष्ट्य शाखा असू शकतात. GitFlow रणनीतीच्या वर्णनाच्या सुरुवातीला चित्राकडे आणखी एक नजर टाका.

शाखा सोडा

जेव्हा विकास शाखेत नवीन वैशिष्ट्यांचा आवश्यक संच तयार असेल, तेव्हा तुम्ही उत्पादनाच्या नवीन आवृत्तीच्या प्रकाशनाची तयारी करू शकता. डेव्हलपमेंट ब्रँचवर आधारित रिलीझ ब्रँच तयार करण्यात आली आहे, ती आम्हाला यामध्ये मदत करेल. रिलीझ शाखेसह कार्य करताना, आपल्याला सर्व दोष शोधणे आणि निराकरण करणे आवश्यक आहे. प्रकाशन शाखा स्थिर करण्यासाठी आवश्यक असलेले कोणतेही नवीन बदल देखील विकास शाखेत परत विलीन करणे आवश्यक आहे. हे विकास शाखा स्थिर करण्यासाठी केले जाते. जेव्हा परीक्षक म्हणतात की शाखा नवीन प्रकाशनासाठी पुरेशी स्थिर आहे, तेव्हा ती मुख्य शाखेत विलीन केली जाते. नंतर या कमिटसाठी एक टॅग, ज्याला आवृत्ती क्रमांक नियुक्त केला जातो, तयार केला जातो. उदाहरण पाहण्यासाठी, रणनीतीच्या सुरुवातीला चित्र पहा. तिथे तुम्हाला Tag 1.0 दिसेल— हा फक्त एक टॅग आहे जो प्रकल्पाची आवृत्ती 1.0 दर्शवतो. आणि शेवटी, आमच्याकडे हॉटफिक्स शाखा आहे.

हॉटफिक्स शाखा

हॉटफिक्स शाखा देखील मास्टर शाखेत नवीन आवृत्ती जारी करण्यासाठी आहेत. फरक एवढाच आहे की त्या रिलीज नियोजित नाहीत. अशी परिस्थिती असते जेव्हा बग रिलीज केलेल्या आवृत्तीमध्ये येतात आणि उत्पादन वातावरणात शोधले जातात. iOS घ्या: नवीन आवृत्ती रिलीझ होताच, रिलीझ झाल्यानंतर आढळलेल्या बग्सच्या निराकरणासह तुम्हाला ताबडतोब अद्यतनांचा एक समूह मिळेल. त्यानुसार, आम्हाला बगचे त्वरीत निराकरण करण्याची आणि नवीन आवृत्ती सोडण्याची आवश्यकता आहे. आमच्या चित्रात, हे आवृत्ती 1.0.1 शी संबंधित आहे. कल्पना अशी आहे की जेव्हा वास्तविक सर्व्हरवरील बगचे निराकरण करणे आवश्यक असते तेव्हा नवीन कार्यक्षमतेवर काम थांबवायचे नसते (किंवा आपण म्हणतो, "प्रॉडमध्ये" किंवा "प्रॉडक्शनमध्ये"). हॉटफिक्स शाखा मास्टर ब्रँचमधून तयार केली जावी, कारण ती सध्या उत्पादनात काय चालत आहे याचे प्रतिनिधित्व करते. दोष निराकरण तयार होताच, ते मास्टरमध्ये विलीन केले जाते, आणि एक नवीन टॅग तयार केला जातो. रिलीझ शाखा तयार करण्याप्रमाणे, हॉटफिक्स शाखेने देखील त्याचे निराकरण विकास शाखेत विलीन केले पाहिजे.

फोर्किंग वर्कफ्लो

फोर्किंग वर्कफ्लोमध्ये, विकासामध्ये दोन भांडारांचा समावेश होतो:

1. मूळ भांडार, ज्यामध्ये सर्व बदल विलीन केले जातील.
2. काट्यांचे भांडार. ही मूळ भांडाराची एक प्रत आहे, जी मूळमध्ये बदल करू इच्छिणाऱ्या दुसऱ्या विकसकाच्या मालकीची आहे.

आतापर्यंत थोडे विचित्र वाटत आहे, बरोबर? ज्याला आधीच मुक्त-स्रोत विकासाचा सामना करावा लागला आहे तो या दृष्टिकोनाशी आधीच परिचित आहे. ही रणनीती खालील फायदे देते: मूळ शाखेत संयुक्त विकासासाठी परवानगी न देता फोर्क रिपॉझिटरीमध्ये विकास होऊ शकतो. स्वाभाविकच, मूळ भांडाराच्या मालकास प्रस्तावित बदल नाकारण्याचा अधिकार आहे. किंवा त्यांना स्वीकारणे आणि विलीन करणे. मूळ भांडाराचे मालक आणि उत्पादन तयार करण्यात मदत करू इच्छिणाऱ्या विकासकासाठी हे सोयीचे आहे. उदाहरणार्थ, तुम्ही लिनक्स कर्नलमध्ये बदल सुचवू शकता . जर लिनसने ठरवले की ते अर्थपूर्ण आहेत, बदल जोडले जातील (!!!).

फोर्किंग वर्कफ्लोचे उदाहरण

तुम्ही वापरू इच्छित असलेली लायब्ररी असताना GitHub वर फोर्किंग वर्कफ्लो लागू केला जातो. यात एक बग आहे जो तुम्हाला ते पूर्णपणे वापरण्यापासून प्रतिबंधित करतो. समजा, तुम्ही समस्येत खोलवर गेलात आणि त्यावर उपाय जाणून घ्या. फोर्किंग वर्कफ्लो वापरून, तुम्ही लायब्ररीच्या मूळ भांडारात काम करण्याच्या अधिकारांशिवाय समस्येचे निराकरण करू शकता. प्रारंभ करण्यासाठी, तुम्हाला काही भांडार निवडण्याची आवश्यकता आहे, उदाहरणार्थ, स्प्रिंग फ्रेमवर्क . वरच्या उजव्या कोपर्यात "फोर्क" बटण शोधा आणि क्लिक करा: यास थोडा वेळ लागेल. मग मूळ भांडाराची एक प्रत तुमच्या वैयक्तिक खात्यात दिसून येईल, जी सूचित करेल की तो काटा आहे:आता तुम्ही या रेपॉजिटरीसह नेहमीप्रमाणे काम करू शकता, मुख्य शाखेत बदल जोडून, ​​आणि जेव्हा सर्वकाही तयार असेल, तेव्हा तुम्ही मूळ रेपॉजिटरीकडे पुल विनंती तयार करू शकता. हे करण्यासाठी, नवीन पुल विनंती बटणावर क्लिक करा:

कोणती रणनीती निवडायची

Git एक लवचिक आणि शक्तिशाली साधन आहे जे तुम्हाला विविध प्रकारच्या प्रक्रिया आणि धोरणे वापरून कार्य करू देते. परंतु तुमच्याकडे जितके अधिक पर्याय असतील, तितकेच कोणती रणनीती निवडायची हे ठरवणे अधिक कठीण आहे. हे स्पष्ट आहे की प्रत्येकासाठी एकच उत्तर नाही. सर्व काही परिस्थितीवर अवलंबून असते. ते म्हणाले, यास मदत करणारी अनेक मार्गदर्शक तत्त्वे आहेत:

1. प्रथम सर्वात सोपी रणनीती निवडणे चांगले. जेव्हा आवश्यक असेल तेव्हाच अधिक जटिल धोरणांकडे जा.
2. विकासकांसाठी शक्य तितक्या कमी शाखा प्रकार असलेल्या धोरणांचा विचार करा.
3. विविध धोरणांचे साधक आणि बाधक पहा आणि नंतर तुम्हाला तुमच्या प्रकल्पासाठी आवश्यक असलेली एक निवडा.

Git मधील ब्रँचिंग स्ट्रॅटेजीजबद्दल मला एवढेच म्हणायचे होते. तुमचे लक्ष दिल्याबद्दल धन्यवाद :) GitHub वर माझे अनुसरण करा , जिथे मी माझ्या कामात वापरत असलेल्या विविध तंत्रज्ञान आणि साधनांचा समावेश असलेली माझी निर्मिती अनेकदा पोस्ट करतो.