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

डायरेक्टम में हमारी टीम प्लेटफॉर्म समाधान के लिए एक विकास उपकरण विकसित कर रही है। यदि आपने 1C देखा, तो आप मोटे तौर पर हमारे "ग्राहकों" के काम के माहौल की कल्पना कर सकते हैं - एप्लिकेशन डेवलपर्स। इस बहुत विकास उपकरण का उपयोग करके, एक एप्लिकेशन डेवलपर ग्राहकों के लिए एक एप्लिकेशन समाधान बनाता है।

हमारी टीम ने हमारे आवेदकों के जीवन को सरल बनाने के कार्य का सामना किया। हम Visual Studio, ReSharper और IDEA से आधुनिक चिप्स के साथ खराब हो गए हैं। आवेदकों ने मांग की कि हम बॉक्स को उपकरण से बाहर एकीकृत करते हैं।

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

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

हमारे प्रैक्टिशनर पूरे रास्ते गए। उन्होंने चुपचाप खुद को हमारे विकास के माहौल की "अवैध" नकल बताया, अवरुद्ध भाग की टिप्पणी की और हमारे कमिट्स को खुद में मिला लिया। एप्लिकेशन कोड को git के तहत रखा गया था, जो थर्ड-पार्टी टूल्स (git bash, SourceTree और अन्य) के माध्यम से प्रतिबद्ध था। हमने अपना निष्कर्ष दिया:

1. हमारी टीम ने मंच में फिट होने के लिए आवेदन डेवलपर्स की इच्छा को कम करके आंका। बड़ा सम्मान और सम्मान!
2. उनके द्वारा प्रस्तावित समाधान उत्पादन के लिए उपयुक्त नहीं है। Git के साथ, एक व्यक्ति के हाथ अनकहे हैं और वह कुछ भी बनाने में सक्षम है। समर्थन करने के लिए सभी विविधता बेवकूफ होगी, अपहरण न करें। इसके अलावा, प्लेटफ़ॉर्म ग्राहकों को शिक्षित करना आवश्यक होगा। प्लेटफ़ॉर्म के लिए सभी git कमांड को डॉक्यूमेंट करने से डॉक्यूमेंटेशन टीम पागल हो जाएगी।

आप गिट से क्या चाहते हैं

तो बाहर एक गिट के साथ उत्पादन के लिए बाहर देना अच्छा नहीं है। हमने मुख्य परिचालन के तर्क को किसी तरह समझाया और उनकी संख्या को सीमित किया। कम से कम पहली रिलीज के लिए। टीमों की सूची कम हो गई थी क्योंकि वे कर सकते थे:

• स्थिति
• प्रतिबद्ध
• पुल
• धक्का
• रीसेट - हेड करने के लिए
• अंतिम "सर्वर" के लिए रीसेट करें

पहली रिलीज के लिए, उन्होंने शाखाओं के साथ काम करने से इनकार करने का फैसला किया। ऐसा नहीं है कि यह बहुत मुश्किल है, बस टीम समय संसाधन को पूरा नहीं करती है।

समय-समय पर, हमारे साथी अपने अनुप्रयोग विकास को भेजते हैं और पूछते हैं: "हमारे लिए कुछ काम नहीं करता है। हम क्या गलत कर रहे हैं?"। इस मामले में, एप्लिकेशन किसी और के विकास के साथ खुद को लोड करता है और कोड में दिखता है। यह इस तरह काम करता था:

1. डेवलपर ने विकास के साथ संग्रह को छीन लिया;
2. कॉन्फ़िगरेशन में स्थानीय डेटाबेस को बदल दिया;
3. अपने आधार पर किसी और के विकास को डाला;
4. डीबग किया गया, त्रुटियां मिलीं;
5. जारी की गई सिफारिशें;
6. उसने अपना विकास वापस कर दिया।

नई कार्यप्रणाली पुराने दृष्टिकोण में फिट नहीं हुई। मुझे अपना सिर फोड़ना पड़ा। टीम ने इस समस्या को हल करने के लिए दो दृष्टिकोण प्रस्तावित किए:

1. एक गिट रिपॉजिटरी में सभी विकास को स्टोर करें। यदि आवश्यक हो, तो अस्थायी शाखा बनाने के लिए किसी और के निर्णय के साथ काम करें।
2. विभिन्न रिपॉजिटरी में विभिन्न टीमों के विकास को स्टोर करें। कॉन्फ़िगरेशन फ़ाइल में पर्यावरण में लोड किए गए फ़ोल्डरों की सेटिंग को स्थानांतरित करें।

हमने दूसरे रास्ते पर चलने का फैसला किया। पहले एक को लागू करना अधिक कठिन लग रहा था और इसके अलावा, शाखा स्विचिंग के साथ अपने आप को पैर में गोली मारना आसान था।

लेकिन दूसरा भी मीठा नहीं है। ऊपर वर्णित कमांड केवल एक ही रिपॉजिटरी के भीतर नहीं, बल्कि कई बार एक साथ काम करना चाहिए। क्या विभिन्न प्रकार के रिपॉजिटरी से इकाई प्रकारों में बदलाव होता है? हम उन्हें एक विंडो में दिखाते हैं। यह एप्लिकेशन डेवलपर के लिए अधिक सुविधाजनक और पारदर्शी है। कमिट बटन दबाकर, उपकरण रिपॉजिटरी में से प्रत्येक में परिवर्तन करता है। तदनुसार, शारीरिक रूप से विभिन्न रिपॉजिटरी के साथ "हुड के तहत" पुल / पुश / रीसेट कमांड।

Libgit2sharp

गिट के साथ काम करने के लिए, हमने दो विकल्पों में से चुना:

1. सिस्टम पर स्थापित git के साथ काम करें, इसे Process.Start के माध्यम से खींचकर आउटपुट को पार्स करें।
2. Libgit2sharp का उपयोग करें, जो pinvoke के माध्यम से libgit2 लाइब्रेरी को खींचता है।

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

पहला विकास यात्रा

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

दूसरा विकास यात्रा

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

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

अंतिम परिणाम इस प्रकार है:

कामवासना से परेशान होना २

लिबिट 2 ने अप्रत्याशित आश्चर्य की एक बड़ी संख्या उत्पन्न की। कुछ से निपटना उचित समय की शक्ति से परे था। मैं आपको बताता हूं कि मुझे क्या याद है।

अप्रत्याशित और कठिन पुन: पेश करने के लिए कुछ मानक संचालन पर पड़ता है। "मूल पुस्तकालय द्वारा प्रदान की गई कोई त्रुटि नहीं" हमें रैपर बताती है। ठीक। आप कोस रहे हैं, आप डिबग में मूल लाइब्रेरी का पुनर्निर्माण कर रहे हैं, आप पहले से गिरा हुआ मामला दोहरा रहे हैं, लेकिन यह डीबग मोड में क्रैश नहीं होता है। रिलीज में पुनर्निर्माण और फिर से गिर जाते हैं।

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

हमारे अनुप्रयोगों में से एक पर, git status एनालॉग के कार्यान्वयन में 40 सेकंड लगे। चालीस कार्ल! इसी समय, कंसोल से लॉन्च किए गए गिट ने काम किया जैसा कि इसे एक सेकंड के लिए करना चाहिए। मैंने इसे सुलझाने के लिए कुछ दिन बिताए। परिवर्तनों की खोज करते समय, लिबजीट 2 फ़ोल्डर्स की फ़ाइल विशेषताओं को देखता है और सूचकांक में प्रविष्टि के साथ उनकी तुलना करता है। यदि संशोधन का समय अलग है, तो फ़ोल्डर के अंदर कुछ बदल गया है और आपको फ़ाइलों को देखने और / या अंदर देखने की आवश्यकता है। और अगर कुछ भी नहीं बदला है, तो आपको अंदर नहीं चढ़ना चाहिए। यह अनुकूलन स्पष्ट रूप से कंसोल गिट में भी है। मैं नहीं जानता कि किस कारण से, लेकिन git index mtime में सिर्फ एक व्यक्ति के लिए बदलाव आया। इसके कारण, परिवर्तन के लिए हर बार git ने रिपॉजिटरी में सभी फ़ाइलों की सामग्री की जाँच की।

जारी करने के करीब, हमारी टीम ने आवेदन टीम की इच्छाओं की fetch + rebase + autostash और git pull को fetch + rebase + autostash साथ बदल दिया। और फिर बग का एक गुच्छा हमारे पास आया, जिसमें "मूल पुस्तकालय द्वारा प्रदान की गई कोई त्रुटि नहीं" भी शामिल है।

कंसोल कमांड को कॉल करने की तुलना में स्थिति, पुल और रिबास बहुत लंबे समय तक काम करते हैं।

ऑटो मर्ज

विकास में फ़ाइलें दो प्रकारों में विभाजित हैं:

1. फ़ाइलें जो एप्लिकेशन डेवलपमेंट टूल में देखती है। उदाहरण के लिए, कोड, चित्र, संसाधन। ऐसी फाइलों को मर्ज किए जाने की आवश्यकता होती है जैसे कि git करता है।
2. JSON फाइलें जो विकास परिवेश द्वारा बनाई गई हैं, लेकिन एप्लिकेशन डेवलपर उन्हें केवल GUI के रूप में देखता है। उन्हें संघर्षों को स्वचालित रूप से हल करने की आवश्यकता है।
3. जेनरेट की गई फाइलें जो डेवलपमेंट टूल के साथ काम करते समय अपने आप रीक्रिएट हो जाती हैं। इन फ़ाइलों को रिपॉजिटरी में नहीं मिलता है, उपकरण तुरंत सावधानी से डालता है।

एक नए तरीके के साथ, दो अलग-अलग एप्लिकेशन एक ही प्रकार की इकाई को बदलने में सक्षम थे।

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

और फिर साशा ने संपत्ति 1 संपत्ति को बदल दिया और इसके लिए एक हैंडलर सेट किया। सर्गेई ने प्रॉपर्टी 2 संपत्ति बनाई और हैंडलर को सेट किया। यदि आप ऊपर से स्थिति को देखते हैं, तो उनके परिवर्तन संघर्ष नहीं करते हैं, हालांकि गिट के दृष्टिकोण से समान फाइलें प्रभावित होती हैं।
मैं चाहता था कि साधन इस स्थिति को अपने दम पर हल करने में सक्षम हो।

संघर्ष के मामले में दो JSON के विलय के लिए एक उदाहरण एल्गोरिथ्म:

1. JSON बेस गिट से डाउनलोड करें।

   
   

2. हमारी JSON गीता से डाउनलोड करें।

   
   

3. उनका JSON एक गिट से डाउनलोड करना।

   
   

4. Jsondiff का उपयोग करते हुए, हम आधार-> हमारे सॉफ्टवेयर पैच बनाते हैं और उनके लिए लागू होते हैं। परिणामी JSON को P1 कहा जाता है।

   
   

5. Jsondiff का उपयोग करके, हम आधार बनाते हैं-> उनके सॉफ्टवेयर पैच और हमारे लिए लागू होते हैं। परिणामी JSON को P2 कहा जाता है।

   
   

6. आदर्श रूप से, पैच लगाने के बाद P1 === P2। यदि ऐसा है, तो P1 को डिस्क पर लिखें।

   
   
7. अपूर्ण स्थिति में (जब एक संघर्ष वास्तव में मौजूद होता है), हम उपयोगकर्ता को अपने हाथों से समाप्त करने की क्षमता के साथ पी 1 और पी 2 के बीच चयन करने का सुझाव देते हैं। हम डिस्क पर चयन लिखते हैं।

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

परिणाम

1. कसाई खुश हैं कि वे कानूनी रूप से उपयोग कर सकते हैं।
2. गिट की शुरूआत ने विकास को गति दी।
3. स्वचालित विलय आमतौर पर जादू की तरह दिखते हैं।
4. हम git प्रक्रिया को लागू करने के पक्ष में libgit2 की भविष्य की अस्वीकृति रखते हैं।