मुझे लगता है कि Git सबमॉड्यूल का उपयोग करना मेरे विकास वर्कफ़्लो के लिए किसी भी तरह से परेशानी भरा है। मैंने गिट उपट्री और गित्सलेव के बारे में सुना है।
जवाबों:
जो आपके लिए सबसे अच्छा है वह आपकी आवश्यकताओं, इच्छाओं और वर्कफ़्लो पर निर्भर करता है। वे कुछ इंद्रियों में अर्ध-आइसोमोर्फिक हैं, यह सिर्फ कुछ विशिष्ट कार्यों के लिए दूसरों की तुलना में उपयोग करने के लिए बहुत आसान है।
gitslave तब उपयोगी होता है जब आप सुपरप्रोजेक्ट की तरह कम से कम एक ही समय में सबप्रोजेक्ट पर नियंत्रण करते हैं और विकसित करते हैं, और इसके अलावा जब आप आम तौर पर एक ही समय में सभी रिपॉजिटरी को टैग, ब्रांच, पुश, पुल आदि करना चाहते हैं। मुझे पता है कि खिड़कियों पर gitslave का परीक्षण कभी नहीं किया गया। इसके लिए पर्ल की आवश्यकता होती है।
git-submodule तब बेहतर होता है जब आप उपप्रोजेक्ट को नियंत्रित नहीं करते हैं या विशेष रूप से उपप्रोजेक्ट को एक विशिष्ट संशोधन पर उपप्रोजेक्ट को ठीक करने की इच्छा रखते हैं, भले ही उपप्रोजेक्ट में परिवर्तन हो। git-submodule git का एक मानक हिस्सा है और इस प्रकार यह विंडोज़ पर काम करेगा।
git-subtree git की बिल्ट-इन सबट्री मर्ज स्ट्रैटेजी को फ्रंट-एंड प्रदान करता है। जब आप एक एकल-रिपॉजिटरी "एकीकृत" गिट इतिहास रखना पसंद करते हैं तो बेहतर है। सबट्री मर्ज की रणनीति के विपरीत, अलग-अलग (डायरेक्टरी) पेड़ों में मूल प्रोजेक्ट के लिए परिवर्तन निर्यात करना आसान है, लेकिन यह स्वचालित नहीं है क्योंकि यह गिट्सवेव या यहां तक कि गिट-सबमॉड्यूल के साथ है।
रेपो थ्योरी में gitslave के समान है, लेकिन गैर-एंड्रॉइड संचालन के लिए प्रलेखित नहीं है जो मुझे मिला है। यह Google Android विकास मॉडल के लिए काफी समर्पित है और केवल मूल रूप से मुट्ठी भर git कमांड का समर्थन करता है (हालांकि आप मनमानी कमांड चला सकते हैं) और सीमित देशी समर्थन समर्थन नहीं करता है, उदाहरण के लिए, एक धक्का देने और बाहर की जाँच करने के लिए एक केंद्रीकृत भंडार शाखा काफी कठिन लगती है।
यदि आप कई संस्करण नियंत्रण प्रणाली का उपयोग करते हैं, तो किटनेट का mr वही है जो आप उपयोग करना चाहते हैं, लेकिन यह सबसे कम सामान्य भाजक दृष्टिकोण के कारण git-only सुपरप्रोजेक्ट के लिए सीमित है। मनमाने ढंग से कमांड चलाने के तरीके हैं, लेकिन वे उतने एकीकृत नहीं हैं।
mr run git config ...या शायद (इससे भी बदतर) नाम के लिए विशिष्ट कमांड को उपनाम करने के लिए कॉन्फ़िग फ़ाइल विधि। बेशक, अगर आप कुछ ऐसे mr फंक्शनलिटी से वाकिफ हैं जो मैन पेज को पढ़ने से स्पष्ट नहीं हैं, तो मैं इसके बारे में जानना चाहूंगा।
git/contrib। sudo make install install-doc prefix=/usr libexecdir=/usr/lib/git-coreएक गीट स्रोत पेड़ से उबंटू में स्थापित करें ( पैक किए गए गिट के साथ काम नहीं करता है )।
विकल्पों की सूची में एक नया अतिरिक्त Git X-Modules है । यह यहाँ वर्णित के रूप में Git Submodules की विशिष्ट कमियों से बचने के लिए है । मुख्य अंतर यह है कि सभी सिंक्रनाइज़ेशन सर्वर की तरफ से किया जाता है, इसलिए अंत उपयोगकर्ताओं के लिए बस एक नियमित रूप से गिट रिपॉजिटरी है जो वे क्लोन करते हैं और धक्का देते हैं।
मैं वर्तमान में विकास के लिए सबमॉड्यूल का उपयोग करता हूं न कि केवल 3 पार्टी पुस्तकालयों से संबंधित। कुछ तरीके हैं जिनसे आप सबमोडुल्स के साथ जीवन को आसान बना सकते हैं, खासकर जब वे मर्ज या रिबेस संघर्ष का स्रोत होते हैं। सबसोड्यूले में संघर्ष पर शामिल 2 कमिट्स प्राप्त करने के लिए ls- ट्री को देखें। लोगों से निपटने के लिए यह शायद सबमॉड्यूल का सबसे कठिन हिस्सा है। अभी के लिए स्क्रिप्टिंग के साथ काम करना बहुत आसान हो जाएगा। भविष्य के संस्करणों को उनसे निपटने के लिए बेहतर देशी समर्थन होना चाहिए।
उम्मीद है की यह मदद करेगा।
हमें परियोजनाओं में गिट सबमॉडल्स का उपयोग करते समय इसी तरह के मुद्दे का सामना करना पड़ा, जहां विभिन्न प्रकार की भाषाओं में हमारी निर्भरता थी। उनसे निपटने के लिए, हमने MDLR ("मॉड्यूलर") नामक एक टूल बनाया और ओपन-सोर्स किया, जो आपको Git सबमॉड्यूल के समान कार्यक्षमता के साथ डिक्लेरेटिव वर्जन-नियंत्रित Git निर्भरता देता है, लेकिन बिना कष्टप्रद वर्कफ़्लो के। आप इसे स्थापित कर सकते हैं और GitHub रेपो पर निर्देशों / डाउनलोड के साथ अपनी निर्भरता का प्रबंधन कर सकते हैं
कुछ उपयोग मामलों के लिए, मुझे निम्नलिखित दो सरल तरीकों में से प्रत्येक पसंद आया है:
नेस्टेड रिपोजिटरी। यदि आपके सॉफ़्टवेयर प्रोजेक्ट में एक प्लगइन मैकेनिज़्म है, जिसके प्रत्येक उप-निर्देशिका में प्रत्येक प्लगइन के साथ, यह इन प्लगइन निर्देशिकाओं को गिट-इग्नोर करने और, आपके स्थानीय फाइल सिस्टम में, उनमें से प्रत्येक को अपने गिट रिपॉजिटरी में बनाने के लिए समझ में आता है। इस तरह, आपकी सभी फाइलें एकल निर्देशिका ट्री बनाती हैं, लेकिन विभिन्न गिट रिपॉजिटरी में प्रबंधित की जाती हैं। यह git को भ्रमित नहीं करेगा।
प्रति-पैकेज रिपॉजिटरी। सॉफ्टवेयर प्रोजेक्ट्स के लिए जहां आप किसी प्रकार के सोर्स कोड पैकेज मैनेजमेंट सिस्टम (जेम / बंडलर, एनपीएम, पीयर या लाइक) का उपयोग करते हैं, यह आपके री-यूज किए गए कोड को अलग-अलग गिट रिपॉजिटरी में डालने का अर्थ बना सकता है, फिर उनसे सोर्स पैकेज बनाने के लिए, और फिर मूल परियोजना में पैकेज प्रबंधन उपकरण के साथ उन्हें स्थापित करने के लिए। आपके मूल प्रोजेक्ट के गिट रिपॉजिटरी में केवल आवश्यक पैकेज और उनके संस्करणों का संदर्भ होगा, जबकि इन पैकेजों के वास्तविक कोड को अन्य सभी पैकेजों और बाहरी पुस्तकालयों के साथ भी किया जाएगा। ऊपर प्रस्तावित नेस्टेड रिपॉजिटरी की तुलना में, यह अधिक विस्तृत दृष्टिकोण है क्योंकि यह निर्दिष्ट करने की अनुमति देता है कि किस पैकेज संस्करण को स्थापित किया जाना है।