2010-01-08 4 views
5

मेरे पास एक स्थानीय गिट भंडार में एक प्रोजेक्ट के दो संस्करण हैं। मुझे इस भंडार को 2 रिमोट रिपॉजिटरीज़ में रखना है, प्रत्येक संस्करण के लिए एक;एक जीआईटी भंडार में एक परियोजना के दो संस्करण को कैसे ट्रैक करें?

स्थानीय GIT (V1/V2) -> रिमोट GIT (V1), REMOTE GIT (V2)

मैं स्थानीय git भंडार जो केवल दूरस्थ GIT (V1) के पास जाना चाहिए में कुछ फ़ाइलें और अन्य चाहिए केवल रिमोट जीआईटी (वी 2) पर जाएं। अब मैं दोनों रिमोट्स के लिए पूर्ण स्थानीय भंडार प्रतिबद्ध करता हूं। क्या मैं केवल कुछ फ़ाइलों को REMOTE1 पर कर सकता हूं?

मुझे प्रोजेक्ट के दोनों संस्करणों को एक भंडार में रखना होगा, लेकिन इतिहास को थोड़ा विभाजित करने के लिए एक विकल्प चाहते हैं। मुझे नहीं लगता कि कोई भी शाखाएं मदद कर सकती हैं, इसलिए मुझे दोनों शाखाओं में समान परिवर्तन करना होगा। अधिकांश कोड, कोड का 9 0% वीईआर 1 और वीईआर 2 के लिए समान है। नया कोड आमतौर पर दोनों संस्करणों के लिए समान होता है।

+0

पहले समझना अच्छा होगा (और यहां पोस्ट करें), आप क्या हासिल करने की कोशिश कर रहे हैं। सबसे छोटा संभव भंडार आकार? वीईआर 2 से बाहर निकलने वाली वीईआर 2 में विलय करने की आवश्यकता है? और कुछ? –

उत्तर

-1

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

+1

submodules आपके स्रोत पेड़ में किसी स्थान पर किसी विदेशी प्रोजेक्ट्रीज़ में किसी अन्य प्रोजेक्ट को एम्बेड करने के लिए हैं। ओपी में केवल एक परियोजना है (विभिन्न शाखाओं के साथ) तो submodules प्रासंगिक नहीं हैं। –

3

ब्रांचिंग बिल्कुल वही है जो आपको चाहिए। शाखाकरण गिट के साथ आसान और बहुत तेज़ है, इसलिए आप कुछ और कुंजीस्ट्रोक के अलावा कुछ भी नहीं खोते हैं।

आप 3 शाखाओं का उपयोग कर सकते हैं। एक "सामान्य" शाखा बनाएं जहां आप "फोर्क" दोनों के लिए आम सामान पर काम करेंगे और काम करने के बाद उनमें विलय करेंगे। विशिष्ट सामानों के लिए, शाखाओं में से एक में काम करें।

गिट फाइल सिस्टम पर हार्ड लिंक का उपयोग करता है ताकि शाखाएं गति और उपयोग की गई जगह दोनों के मामले में सस्ते हों।

अंत में, आप हमेशा चुन सकते हैं कि कौन सी शाखा पुश/पुल करने के लिए चुनती है।

+1

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

+0

सुधार के लिए धन्यवाद, मैंने इसे अभी तय कर दिया है। –

+0

@ रैंडल: एसवीएन फाइल सिस्टम हार्ड लिंक का उपयोग नहीं करता है। एसवीएन में एक शाखा भी सस्ता है क्योंकि यह "सिर्फ एक प्रतिबद्धता" है। केवल अंतर यह है कि एसवीएन सस्ती फ़ाइल/फ़ोल्डर प्रतियों में, शाखाएं और टैग सभी एक ही तंत्र द्वारा बनाए जाते हैं, जबकि गिट शाखाओं में एक अलग अवधारणा होती है। –

0

तीन गिट भंडार बनाएं: core, app_1, app_2app रिपॉजिटरीज़ में से प्रत्येक के भीतर, core भंडार का संदर्भ देने वाला गिट सबमिशन बनाएं।

एक शुद्ध पुस्तकालय के रूप में core भंडार और शुद्ध लाइब्रेरी उपभोक्ताओं के रूप में app खजाने इलाज, तीन परियोजनाओं की संरचना ऐसी है कि आप सब कुछ core भंडार और सब कुछ में दो "संस्करण 'है कि दोनों के बीच वितरित हो जाते हैं के लिए आम रख सकते app भंडारों में संस्करण। app भंडारों का ढांचा core प्रोजेक्ट app भंडारों के भीतर एक उपनिर्देशिका में, कोई संशोधन के साथ थोक रखा जा सकता है। आपको सभी app रिपॉजिटरीज़ के बीच साझा की गई न्यूनतम सामान्य प्रारंभिक स्क्रिप्ट की आवश्यकता हो सकती है, लेकिन यह भुगतान करने के लिए एक छोटी सी कीमत है।

इस तरह से कोड को संरचित करने का परिदृश्य बहुत आम है। यद्यपि इस कोड आर्किटेक्चर परिदृश्य का समर्थन करने के लिए इस तरह गिट का उपयोग करना बहुत कम आम है, इसे व्यवहार्य संभावना के रूप में देखा जाता है।