Git: शाखा या कांटा?


17

मेरे पास एक गेम प्रोजेक्ट है जिसमें दो संस्करण होंगे:

  1. खेल का एक सरल संस्करण, कोर।
  2. खेल का एक उन्नत संस्करण।

मेरे सार्वजनिक भंडार में मेरा पहला संस्करण है, और केवल मैं इस पर काम करूंगा। दूसरे संस्करण के लिए, मेरे और मेरे दो दोस्त इस पर काम करेंगे। महत्वपूर्ण हिस्सा यह है कि मैं चाहता हूं कि दो संस्करण मेरे भंडार में रहें।

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

मेरे लिए यहां क्या विकल्प हैं? मैं अपने भंडार में दोनों संस्करणों को कैसे रख सकता हूं?


3
एक कांटा एक शाखा है, बस दूसरे स्थान पर संग्रहीत है।

@ मिचेल्ट ओके। क्या कांटे का मतलब शाखाओं की तरह किसी बिंदु पर विलय करना है?
वाराक्विलेक्स

22
कांटा एक गितुब कांसेप्ट है, गिट कांसेप्ट नहीं। यह केवल क्लोन करता है और इसे आपके खाते में डालता है। तो क्लोनिंग आप के लिए क्या देख रहे हैं। देखें stackoverflow.com/questions/6286571/git-fork-is-git-clone
PDR

@Varaquilex वे दोनों भंडार आपको एक ही भंडार में रखने की आवश्यकता होगी? इसके अलावा forkएक रिपॉजिटरी में प्रवेश करने से आपके खाते में एक नया भंडार बन जाएगा।
महदी

1
केवल एक ही संस्करण क्यों नहीं है जो सरल मोड या उन्नत मोड में चल सकता है? बेशक कोड के कुछ भाग केवल सरल में सक्रिय होंगे और कुछ भाग केवल उन्नत में सक्रिय होंगे, लेकिन मुझे लगता है कि बहुत कुछ साझा किया जाएगा।
बीडीएसएल

जवाबों:


11

मेरे लिए ऐसा लगता है कि आपको दो शाखाओं की नहीं बल्कि दो रिपॉजिटरी की जरूरत है । एक शाखा एक एकल भंडार के भीतर परिवर्तनों को संभालने के लिए एक तंत्र है ताकि अंततः उन्हें बाकी कोड के साथ मिला दिया जा सके।

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

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


6

प्रश्न का उत्तर "मुझे क्लोन या कांटा करना चाहिए" इस प्रश्न के उत्तर के समान है "क्या मुझे इस परियोजना का अपना व्यक्तिगत संस्करण चाहिए?" हाँ = कांटा, नहीं = भंडार का क्लोन।

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

कई सार्वजनिक परियोजनाओं ने मुख्य परियोजना से बाहर काम कर रहे बदलावों को रखने के लिए परियोजना को कांटा है।

चरण 2 के लिए, प्रोजेक्ट को कांटा करें फिर इसे अपने काम करने वाले कंप्यूटर पर क्लोन करें और अपने दोस्तों को भी ऐसा ही करें।


मैं अपनी खुद की परियोजना को कैसे कांटा सकता हूं?
वारेक्विलेक्स


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

0

क्या यह वास्तव में लगता है जैसे आप चाहते हैं एक सबमॉड्यूल है। यदि आप पहले रेपो (अपने निजी सरल रेपो) का निर्माण करते हैं और फिर इसे एडवांस्ड वर्जन रेपो में सबमॉड्यूल के रूप में जोड़ते हैं, तो आपको प्राइवेट रेपो को विकसित करने के लिए एडवांस्ड रेपो में बदलाव को ट्रैक करने और खींचने में सक्षम होना चाहिए।


1
कई लोगों ने रेयान की प्रतिक्रिया के लिए समय लिया है, लेकिन टिप्पणी देने का समय नहीं लिया है, और यह व्यवहार एसओ के दिशानिर्देशों की भावना के खिलाफ है। यदि ओपी के प्रश्न में, "कोर" दोनों पेड़ों में समान था, तो कोर के चारों ओर एक "सरल" और "उन्नत" रैपर दोनों होते हैं, तो यह उत्तर कम से कम उचित है।
स्कॉट प्रिव

मैंने उत्थान किया है, लेकिन उसे शायद आपकी तरह एक स्पष्टीकरण शामिल करना चाहिए जो बताता है कि एक सबमॉड्यूल अच्छा क्यों होगा, और यह कैसे काम करेगा। एक पुस्तकालय में आम कोड को विभाजित करना जिसे एक सबमॉड्यूल के रूप में शामिल किया जा सकता है, एक अच्छा विचार है, लेकिन यह निर्दिष्ट किए बिना कि एक सबमॉडल का सुझाव दिया जाना चाहिए तुरंत समझ में नहीं आता है।
शॉन बर्टन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.