git vendor विस्तार की खोज।

मेरे मीडियम ब्लॉग से क्रॉस-पोस्ट: https://medium.com/opsops/git-vendor-295db4bcec3a

मैं git रिपॉजिटरी की वेंडरिंग को संभालने के लिए उचित तरीके का परिचय देना चाहूंगा।

'वेंडरिंग ’क्या है?

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

आम तौर पर, भाषा टूलींग द्वारा वेंडरिंग किया जाता है: बंडल, कार्गो, पाइप, आदि। लेकिन कभी-कभी आपको किसी भी मौजूदा टूलसेट, या कुछ मल्टी-लैंग्वेज द्वारा कवर किए गए वेंडर की आवश्यकता होती है, कि उसके लिए 'कोर' भाषा टूल को ढूंढना असंभव है।

इस स्थिति का समाधान जीआईटी स्तर पर है। आपके पास अपनी खुद की गिट रिपॉजिटरी है (मैं इसे ' डेस्टिनेशन रेपो ' कहता हूं), और आप कुछ अन्य रिपॉजिटरी (मैं इसे ' सोर्स रेपो ' कहते हैं) को डायरेक्टरी के रूप में अपने (डेस्टिनेशन रेपो) में शामिल करना चाहते हैं।

अच्छी तरह से डिजाइन किए गए प्रतिशोधी प्रणाली से आप जिन चीजों की उम्मीद करते हैं (इसकी परवाह किए बिना कि यह है या नहीं):

• दृश्यता। आप जानना चाहते हैं कि कुछ कोड वंचित है, इसका मतलब यह नहीं है कि कमिट द्वारा लिखा गया था।
• उद्गम। आप जानना चाहते हैं कि यह कहां से आता है। दो साल पहले आपके रेपो में किसी को कैसे रिपॉजिटरी एकीकृत किया गया था? और क्या संस्करण / प्रतिबद्ध था?
• Updatability। आप उस कोड को अपडेट करने में सक्षम होना चाहते हैं जब उसे मूल रेपो में कुछ बग ठीक हो जाते हैं (या एक नई लंबी प्रतीक्षा वाली सुविधा होती है)। Updatability के लिए विशेष मामले के रूप में आप सत्यापित कोड (और केवल इसे) को हटाने में सक्षम होना चाहते हैं।
• Repeatability। वेंडरिंग कला नहीं होनी चाहिए, यह कठोर त्रुटि प्रूफ प्रक्रिया होनी चाहिए। विक्रेता फू बार में वही परिणाम प्राप्त करना चाहिए जो किसी ने भी नहीं किया हो।
• Transportability। आपकी रिपॉजिटरी का क्लोन करने वाला व्यक्ति वैसा ही व्यवहार करने में सक्षम होना चाहिए जैसा आपने किया था। इसका मतलब यह है कि सभी प्रतिशोधी-संबंधित जानकारी को गेट में रहना चाहिए और पुश / पुल के दौरान स्थानांतरण करना चाहिए।
• शासन। जब तक कोई उन्हें अपडेट नहीं करता है तब तक सभी परिवर्तनशील परिवर्तन 'बने रहने चाहिए'। आप अनपेक्षित (ब्रेकिंग) अपडेट नहीं चाहते हैं, इसके अलावा, आप पूरी तरह से वंचित सामान भी उपलब्ध रखना चाहते हैं, यहां तक ​​कि स्रोत रेपो भी उपलब्ध नहीं है।
• Patchability। आप सत्यापित कोड को ट्विक करने में सक्षम होना चाहते हैं और फिर भी इसे नए संस्करण में अपडेट करने में सक्षम हो सकते हैं। अधिमानतः, संघर्षों के बिना, लेकिन कम से कम, स्पष्ट दृश्यता के साथ जहां वे संघर्ष हुए थे।

और, गिट की प्रकृति को देखते हुए, आप चाहते हैं कि यह प्रणाली शाखा के अनुकूल हो। यदि शाखा ए के पास संस्करण ए 1 में कोड है, और संस्करण बी 1 पर शाखा बी है, तो आप ए और बी के बीच स्विच करने के बाद हर बार उनके बीच स्विच करना चाहते हैं। इसके अलावा, आप संस्करण ए 1 को ए 2 और संस्करण बी 1 में बदलने में सक्षम होना चाहते हैं। एक अन्य शाखा में संस्करणों के बारे में चिंता किए बिना b2।

... और आप एक से अधिक बाहरी रिपॉजिटरी के लिए विक्रेता बनना चाहते हैं, इसलिए रेपिंग प्रति रेपो के लिए एक बार की घटना नहीं होनी चाहिए।

जैसा कि आप देख सकते हैं कि यह आवश्यकताओं की एक लंबी सूची है। मैंने सबसे अच्छा समाधान (गिट विक्रेता) प्राप्त करने से पहले मौजूदा (अन्य) समाधानों का विश्लेषण किया।

कॉपी पेस्ट करें

कॉपी-पेस्ट किसी भी चीज़ को विक्रेता के लिए इतना शातिराना तरीका है कि मुझे इसके बारे में कहने के लिए कुछ भी अच्छा नहीं है। आप ढीले साबित, दृश्यता, updatability। हालांकि, आप ट्रांसपोर्टेबिलिटी को ढीला नहीं करते हैं, क्योंकि पुरानी रेपो का कोई लिंक नहीं है। इस तरह से वेंडरिंग मत करो।

Git में Git

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

पेशेवरों: करने के लिए सरल है, स्थानीय सिद्धता, शासन और एक उत्कृष्ट patchablity प्रदान करते हैं।

विपक्ष: यह भंगुर है, यह पुश नहीं बचता है (नेस्टेड .it फ़ोल्डर आपके रेपो में शामिल नहीं है, इसलिए बाहरी पर्यवेक्षकों के लिए यह कोड आपके स्वयं से अप्रभेद्य है)। तो आप लंबे समय में परिवहन क्षमता, और एक सिद्धता को ढीला कर देंगे।

submodules

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

और यह मत भूलो कि इस रेपो का क्लोन बनाना कितना कठिन है।

गिट उपट्री

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

तो, पुरस्कार विजेता, गिट विक्रेता दर्ज करें।

गिट विक्रेता

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

यह git सबट्री का उपयोग करता है और इसे git सबट्री द्वारा रेंडरिंग के ढीले पक्षों को कवर करने के लिए फ़ंक्शंस के साथ विस्तारित करता है।

हर महत्वपूर्ण बिंदु की जाँच की जाती है:

• visilibity। बस git vendor list कॉल करें और सभी सत्यापित सामान देखें।
• उद्गम। यह दूरस्थ रेपो दिखाता है और यह देखने की अनुमति देता है कि क्या प्रतिबद्ध था।
• updatability। git vendor update , और यह शाखाओं, टैग के लिए समर्थन करता है और एक तरह से पिन-पॉइंट के रूप में होता है जो वास्तव में लेना है। और आप निश्चित रूप से git vendor remove सकते हैं।
• repeatability। इसमें कोई मैनुअल ऑपरेशन शामिल नहीं है, इसलिए सभी को प्रारंभिक प्रतिशोध या निम्नलिखित अपडेट पर समान परिणाम मिलेगा।
• परिवहनीयता। सभी परिवर्तन गिट इतिहास में एक विशेष टैग के रूप में संग्रहीत किए जाते हैं, इसलिए वे पूरी तरह से पुश / पुल-फ्रेंडली हैं। और वे शाखाओं और मनमाने ढंग से इतिहास के चेकआउट के साथ महान काम करते हैं।
• govenrance। सभी प्रतिशोधित कोड आपके रेपो के अंदर संग्रहीत किए जाते हैं।
• patchability। यह है (आप अपने परिवर्तनों के साथ एक स्पष्ट मर्ज संघर्ष देखेंगे), लेकिन यह गिट विक्रेता का सबसे कमजोर पक्ष है। मैं 'पैच कतार' (जैसे डेब / पाथ इन डेब्यू पैकेज के लिए) को पसंद करूंगा, लेकिन फिर भी, इसके लिए एक न्यूनतम समर्थन है।

सामान कैसे वंचित है, इसकी विशिष्ट नीति है: यदि आप https://github.com/serverscom/dibctl का क्लोन बनाना चाहते हैं तो यह vendor/github.com/serverscom/dibctl/ में चला जाता है। आप ' vendor/ ' भाग को बदल सकते हैं, लेकिन बाकी एक कठिन नीति है। साइमलिंक आसान कर सकते हैं, हालांकि।

वहाँ कुछ छोटे कीड़े हैं: आप इसे खाली रेपो पर उपयोग नहीं कर सकते हैं, आप स्रोतों के रूप में स्थानीय गिट्स का उपयोग नहीं कर सकते, आप तब तक मदद नहीं देख सकते जब तक आप गिट रेपो में नहीं होते। उनमें से कोई भी वास्तविक रेपो के साथ सामान्य काम के दौरान समस्याएं पैदा नहीं करता है।

निष्कर्ष

git-seller एक git repo को दूसरे में वेंडर करने के लिए एक सही उपकरण है। यह प्रतिशोध की सर्वोत्तम प्रथाओं के लिए सभी आवश्यक कार्यक्षमता प्रदान करता है: सिद्धता को बनाए रखना, दृश्यता और अद्यतनता प्रदान करना।