मर्जिराफ - गिट में एएसटी-उन्मुख तीन-तरफ़ा मर्ज उपकरण

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

नीचे मर्जिराफ़ का उपयोग करके हल की गई समस्याओं का विस्तृत विवरण दिया गया है:

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

उत्पादों के संदर्भ में, प्रत्येक नोड को "संस्करण" कहा जाता है, जो कार्यों और विरोधी कार्यों के एक विशिष्ट सेट का प्रतिनिधित्व करता है। इस सेट में किसी भी बदलाव को उत्परिवर्तन माना जाता है, जो हमारे निर्देशित चक्रीय ग्राफ में बढ़त बनाता है। ये कार्य स्वाभाविक रूप से अमूर्त हैं; वे सीधे तौर पर भौतिक प्रणालियों के संचालन के तरीकों को प्रतिबिंबित नहीं करते हैं, बल्कि यह प्रदर्शित करते हैं कि बुद्धिमान एजेंट उन प्रणालियों की उपयोगिता को कैसे समझते हैं। विचारों को वास्तविक दुनिया के कार्यान्वयन में अनुवाद करने के लिए, आपको अपनी आस्तीन ऊपर चढ़ानी होगी और *पर्याप्त* निम्न-स्तरीय विवरणों में गोता लगाना होगा जो व्यक्त कर सकें और स्पष्ट कर सकें कि चीजें कैसे काम करती हैं। सॉफ़्टवेयर विकास में, इन निम्न-स्तरीय को आमतौर पर स्रोत कोड द्वारा दर्शाया जाता है।

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

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

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

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

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

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

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

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

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

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

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

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

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

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

काम पर उदाहरण: सामान्य पूर्वज "base.py" (इंडेंटेड टैब, शुरुआत में अतिरिक्त लाइन) foo = 1 def main(): print(foo + 2 + 3) "a.py" (इंडेंटेड स्टिल टैब, 2 अतिरिक्त लाइनें) शुरुआत में, एक के बजाय, डिबग प्रिंटिंग के लिए आइसक्रीम लाइब्रेरी का उपयोग किया जाता है, "बाज़" वर्ग जोड़ा जाता है: आइसक्रीम आयात से आईसी फू = 1 डीईएफ़ मुख्य (): आईसी (फू + 2) +3) वर्ग बाज़: def __init__(self): """baz""" "b.py" (वेरिएबल "फू" का नाम बदलकर "बार" कर दिया गया है, परिवर्तन के बाद "ब्लैक" के साथ संसाधित किया गया है, जिसके परिणामस्वरूप रिक्त स्थान और अतिरिक्त के साथ इंडेंटेशन हुआ है लाइनें कट जाती हैं): बार = 1 डीईएफ़ मुख्य(): प्रिंट(बार + 2 + 3) कॉल ./mergiraf मर्ज ./base.py ./a.py ./b.py -x a.py -y b.py -s Base.py -o ./res.py आइसक्रीम आयात ic bar = 1 def main() से निम्नलिखित परिणाम देता है: ic(bar + 2 + 3) class baz: def __init__ (स्वयं): """बाज़"" (डीबग प्रिंटिंग के लिए, "आइसक्रीम" लाइब्रेरी का उपयोग किया जाता है, "फू" वेरिएबल का नाम बदलकर "बार" कर दिया जाता है, परिवर्तनों के बाद "ब्लैक" के साथ संसाधित किया जाता है, जिसके परिणामस्वरूप इंडेंटेशन होता है - रिक्त स्थान और अतिरिक्त लाइनें काट दी गईं, इंडेंटेशन के लिए टैब और रिक्त स्थान का मिश्रण, लेकिन अनुमत रूप)।

किसी उपकरण की कमी तुरंत नजर आने लगती है. दस्तावेज़ शैली आमतौर पर .editorconfig फ़ाइलों में कॉन्फ़िगर की जाती है, और वैश्विक शैली परिवर्तन, जैसे टैब को रिक्त स्थान में बदलना और काली शैली को अपनाना, जैसा कि b.py में किया जाता है, आमतौर पर .editorconfig में परिवर्तन के साथ होते हैं। इसलिए, ऐसे परिवर्तनों के अधिक सही अनुप्रयोग के लिए, टूल में वैश्विक "डिफ़ॉल्ट" शैली की अवधारणा होनी चाहिए, और ".editorconfig" से सेटिंग्स खींचने में सक्षम होना चाहिए।

स्रोत: opennet.ru