गिट शाखा को गिट टैग में परिवर्तित करने के लिए

Question

मैं एक गिट शाखा को गिट टैग में बदलने के लिए सबसे अच्छा और सुरक्षित तरीका ढूंढ रहा हूं। हाथ से एक एसवीएन भंडार पर पोर्टिंग करते समय, मैंने मूल रूप से हमारी सभी शाखाओं पर प्रतिलिपि बनाई और हमारे पास प्रत्येक मामूली रिलीज (1.1, 1.2, 1.3) के लिए एक शाखा थी, जो सभी ईमानदारी में संभवतः ऐसा करने का सबसे अच्छा तरीका नहीं था, लेकिन इसके लिए गति, मैं उस समय टैग की तुलना में शाखाओं के साथ अधिक आरामदायक था। अब मेरे पास शाखाएं 1.5, 1.6, 1.7, 1.8 हैं, हालांकि हमारे पास कभी भी किसी भी समय दिए गए कोड का 1 संस्करण है, इसलिए शायद मुझे केवल उस संस्करण में जाने के लिए अंतिम संस्करण की आवश्यकता है जो किसी भी हॉट फिक्स को उस संस्करण में जाने की आवश्यकता है तैनात किया गया है तो मैं एक गिट शाखा को गिट टैग में बदलने का सबसे अच्छा तरीका ढूंढ रहा हूं। मुझे लगता है कि मेरे पास एक रास्ता है लेकिन यह सुनिश्चित किया कि यह कितना अच्छा है।

मैं अब तक क्या किया प्रत्येक शाखा मैं किसी टैग से परिवर्तित करना चाहते हैं के लिए है, मुझे यकीन है कि वहाँ जो शाखाओं कि मास्टर शाखा में नहीं हैं में कोई प्रतिबद्ध हैं बनाने के लिए जाँच की है, तो मैं क्या किया:

git log 1.5 ^master 
git log 1.6 ^master 
git log 1.7 ^master 

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

git tag 1.5v 1.5 
git tag 1.6v 1.6 
git tag 1.7v 1.7 

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

यह भी एक चिंता है कि अगर किसी ने शाखा 1.7 (जिसे कोई भी नहीं होना चाहिए) से शाखा बनाई है और वे उस शाखा को हटाने वाले परिवर्तनों को खींचते हैं, तो क्या वे उन परिवर्तनों को किसी अन्य शाखा में विलय करने में सक्षम होंगे (मास्टर कहें) या उस तरह की शाखा को तोड़ने का वह प्रकार होगा? यह एक ऐसा मामला है जो ऐसा नहीं होना चाहिए क्योंकि किसी भी व्यक्ति को पिछले संस्करण के अलावा किसी भी शाखा संस्करण से शाखाओं को बंद नहीं किया जाना चाहिए, इस मामले में 1.8, लेकिन लोग हमेशा प्रक्रिया का पालन नहीं करते हैं इसलिए मैं यह सुनिश्चित करना चाहता हूं कि एक तरीका है अगर ऐसा होता है तो इसे ठीक करने के लिए।

Answer 1

संक्षिप्त उत्तर: यह कोई समस्या नहीं है। और आपके द्वारा प्रस्तावित टैग बनाने के तरीके ठीक है, हालांकि मेरा सुझाव है कि आप टिप्पणी के साथ एनोटेटेड टैग बनाने के लिए -m विकल्प का उपयोग करें (man git-tag देखें), क्योंकि यह "प्रथम श्रेणी" टैग बनाएगा जिसका उपयोग git describe आदि द्वारा किया जाएगा अतिरिक्त तर्क

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

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

svn से git तक आने से पहले थोड़ा उलझन में हो सकता है। ऐसा लगता है कि आप अभी भी svn शर्तों में सोच रहे हैं, जिससे सबकुछ अधिक भ्रमित हो रहा है। मुझे लगता है कि अगर आप एक स्रोत नियंत्रण उपकरण के बजाय, एक उन्नत फाइल सिस्टम (जो लिनस टोरवाल्ड्स ने लिखा था) के रूप में गिट के बारे में सोचते हैं तो यह आसान है। मैं यह भी सुझाव देता हूं कि git for computer scientists पढ़ने के लिए आपको कुछ समय दें (या स्किम करें), यह उतना ही कठिन नहीं है जितना लगता है; और यह वास्तव में काम करने की बेहतर समझ रखने से आपको "सही तरीके" सोचने में मदद मिलेगी। ;)

Answer 2

जैसा कि मैं इसे समझता हूं, आप शाखाओं के बजाय टैग बनाना चाहते हैं और इस प्रकार दूसरों को इन शाखाओं पर जारी रखने के लिए रोकना चाहते हैं।

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