पूरी तरह से अलग सामग्री के साथ गिट शाखाएं

Question

चूंकि गिट में एक ही भंडार में एक दूसरे से पूरी तरह से अलग सामग्री के साथ शाखाओं को ट्रैक (और इसे साफ रखना) रखने की क्षमता है, कुछ परियोजनाओं (जैसे गिट स्वयं) ने उपयोग करना शुरू कर दिया है इसका

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

यह सिर्फ मुझे हो सकता है, एसवीएन पृष्ठभूमि से आ रहा है, लेकिन मुझे लगता है कि उन शाखाओं में 'सामान्य में कुछ भी नहीं' है। विकास/स्टेजिंग/उत्पादन शाखाएं; मैं समझता हूँ। अपूर्ण सुविधाओं के लिए शाखाएं; यकीन है, मैं भी उनको कर रहा हूँ। बिल्ली, प्रति दस्तावेज एक शाखा के साथ अपने दस्तावेज है। लेकिन कोई फाइल आम नहीं है?

क्या यह गिट में बस (शायद एक अंतर्निहित और/या अनारक्षित) सुविधा है, कि हर किसी को एक ही परियोजना के दो पहलुओं को अलग करने के आलसी होने के आलसी होने के कारण गले लगाना और संभवतः खतरनाक दुरुपयोग करना चाहिए?

Answer 1

मैं व्यक्तिगत रूप से विभिन्न शाखाओं में अलग-अलग सामग्री संग्रहीत नहीं करता; दस्तावेज़ों और कोड के मामले में, मैं सिर्फ myproject.git और myproject-docs.git (और बिल्ड प्रक्रिया में आवश्यक होने पर दस्तावेज़ में दस्तावेज़ों को उप-मॉड्यूल) बनाउंगा।

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

Answer 2

ऐसा करने का लाभ यह है कि यदि आप रुचि रखते हैं तो केवल डॉक्स शाखा को खींचना संभव है। जैसे ही जर्कोवे ने कहा, आप इसे एक और भंडार का उपयोग करके और यदि आवश्यक हो तो सबमिल्डिंग कर सकते हैं, लेकिन इस क्षमता के साथ एक 'नग्न' शाखा बनाएं, आपके पास विकल्प नहीं है।

व्यक्तिगत रूप से, मैं अभी भी इस बारे में बाड़ पर हूं। मैं समझता हूं कि यह फायदेमंद क्यों हो सकता है, लेकिन मुझे पूरी तरह से आश्वस्त नहीं है कि यह जाने का सबसे अच्छा तरीका है।

Answer 3

यह थोड़ा अजीब है जब आप उपयोगकर्ताओं को पेड़ पेश करने के सबवर्जन मॉडल में उपयोग करते हैं, लेकिन एक बार जब आप मॉडल में उपयोग करते हैं तो यह बहुत कम भ्रमित होता है।

एक गिट भंडार केवल वस्तुओं का एक पेड़ है जो बताता है कि एक राज्य से दूसरे राज्य में निर्देशिका को कैसे परिवर्तित किया जाए। उन वस्तुओं में एक माता पिता है। कुछ वस्तुओं में दो (या अधिक) माता-पिता होते हैं; विलीन हो जाती है। कुछ वस्तुओं में कोई माता पिता नहीं होता है; प्रारंभिक प्रतिबद्धता

जैसा कि मैं इसे समझता हूं, आंतरिक रूप से, सबवर्जन का मॉडल इसी तरह की अवधारणा है कि विलय कहां से आया था। दो अन्य कामों के बीच मतभेदों का एक पैच प्राप्त करने के लिए वे एक आसान कमांड (svn merge) के साथ बस नए काम करते हैं।

मैं वास्तव में इस सुविधा का उपयोग अक्सर कॉन्फ़िगरेशन फ़ाइलों को प्रबंधित करने के लिए करता हूं जो अलग मेजबानों पर उसी निर्देशिका से शुरू होते हैं, जैसे /etc/apache2। यह कहने जैसा है, "यह इस सामान की वैकल्पिक शुरुआत है, लेकिन इसे छोड़ दिया गया है"। इससे पहले कि मैं उन्हें ओवरराइट करने से पहले कुछ फ़ाइलों की स्थिति को छीनने की अनुमति देता हूं, लेकिन इस बारे में चिंता किए बिना कि वे सही विलय करते हैं या मास्टर शाखा से भी संबंधित हैं।

सबवर्सन में मुझे उस बैकअप को कुछ गैर-संबंधित स्थान (ज़िप फ़ाइल कहीं कहीं) या भंडार में उपनिर्देशिका में रोकना होगा। इसके अलावा, उपversण में, यदि मैं पेड़ के वर्तमान दृश्य में उन फ़ाइलों के किसी भी संदर्भ को हटा देता हूं तो उन्हें फिर से ढूंढना बहुत मुश्किल हो जाता है।

Answer 4

मैं कहूंगा कि यह इस तथ्य के लिए आलसी कामकाज की तरह है कि गिट वर्तमान में एक ही भंडार में संग्रहीत कई परियोजनाओं को संभाल नहीं सकता है। आप इसे कर सकते हैं, लेकिन केवल वही व्यक्ति खींचने का कोई तरीका नहीं है जिसे आप चाहते हैं।

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

Answer 5

मुझे लगता है कि यह आपकी परियोजना पर निर्भर करता है।

गिट स्पष्ट रूप से एक समुदाय ओएसएस प्रोजेक्ट है, इसलिए (उसी) भंडार में दस्तावेज़ होने के कारण हर कोई उन्हें समझ में आता है (मेरे लिए)।

दूसरी ओर मैं काम पर अपनी परियोजनाओं के लिए दस्तावेज़ों को संग्रहीत नहीं करता क्योंकि मैं 'डॉक्स' अपडेट के टिकट को छोड़कर उन्हें संपादित करता हूं। काम पर मैं नहीं चाहता कि मेरे दस्तावेज़ मेरे स्रोत के साथ मिल जाए, मैं सिर्फ स्रोत चाहता हूं (सामान्य प्रोग्रामर दृश्य मुझे पता है)।

अन्य लोग उन्हें एक साथ चाहते हैं। मुझे लगता है कि आपको यह समझने की जरूरत है कि इसका क्या अर्थ है (याद रखें कि सभी के पास भंडार की पूरी प्रति है) और अपनी परियोजना के लिए सबसे अच्छा विकल्प चुनें।

Answer 6

गिट एक परियोजना के भीतर (पाठ) फ़ाइलों में समन्वयित परिवर्तन ट्रैक करता है, इसलिए यह नहीं जानता है कि शाखाएं विलय योग्य हैं या नहीं। एक गिट रेपो में स्वतंत्र शाखाएं होने के कारण एक सबवर्जन रेपो में स्वतंत्र परियोजनाएं होती हैं, जो एक आम प्रथा है (svn के ऊपरी हिस्से की वजह से)।

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

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

जैसा कि मैंने Git, क्या किया गया था अजीब सिर्फ अलग बन के और अधिक अनुभव मिला है। तब मैं उत्सुक हो गया कि मैं उस अलग टूल के साथ क्या कर सकता था।