क्षमा करें यदि यह एक डुप्लिकेट है, तो मैंने देखा।
हम Git के लिए आगे बढ़ रहे हैं। तोड़फोड़ में, मैं \ trunk, \ शाखाओं और \ टैग फ़ोल्डर रखने के लिए उपयोग किया जाता हूं।
Git के साथ, शाखाओं के बीच स्विच करने से वर्किंग डायरेक्टरी की सामग्री बदल जाएगी, तो क्या मुझे यह मान लेना सही है कि जिस तरह से हम काम करते थे, वह Git के साथ लागू नहीं होता है?
मेरा अनुमान है कि मेरे पास शायद एक gitignore और readme.txt के साथ एक रेपो फ़ोल्डर होगा, फिर रेपो बनाने वाली परियोजनाओं के लिए फ़ोल्डर, और यही वह है।
जवाबों:
आपके पास "ट्रंक" होगा, जिसे अब "मास्टर" कहा जाता है, आपके पास "शाखाएं" होंगी, जिन्हें अब "हेड" कहा जाएगा और आपके पास "टैग" होंगे, फिर भी "टैग" कहलाएंगे, लेकिन वे फ़ोल्डर नहीं होंगे , वे "होंगे" रेफ्स ", उन संशोधनों के लिए लेबल जो रिपॉजिटरी के अंदर अलग नामस्थान में रहते हैं।
तोड़फोड़ करने के लिए तोड़फोड़ और गिट के अलग-अलग तरीके हैं। मूल तोड़फोड़ मॉडल में एकल वैश्विक समयरेखा के साथ एक निर्देशिका पेड़ होना है और यदि आप शाखा करना चाहते हैं, तो आप किसी अन्य निर्देशिका में एक उपप्रकार की प्रतिलिपि बनाएँ।
दूसरी ओर, Git में संशोधन के साथ एक निर्देशिका वृक्ष है जो प्रत्येक को उसके माता-पिता को परिभाषित करता है, लेकिन प्रत्येक संशोधन में कई माता-पिता (एक मर्ज) और कई बच्चे (शाखाएं) हो सकते हैं। इसलिए शाखाओं के लिए निर्देशिका होने के बजाय, आप स्वतंत्र रूप से बनाए गए संशोधन प्राप्त करते हैं। "रेफ्स" केवल "शाखा" के लिए नवीनतम संशोधन से जुड़े नाम हैं।
यह अंतर वितरित संस्करण नियंत्रण के लिए मौलिक है। गिट (और अन्य वितरित सिस्टम) के पास इतिहास को रैखिक रखने के लिए कोई केंद्रीय प्राधिकरण नहीं है, इसलिए एक-दूसरे के बारे में जाने बिना कई रिपॉजिटरी पर स्वतंत्र रूप से संशोधन किए जा सकते हैं और सिस्टम को उन्हें समायोजित करना होगा। यह पता चलता है कि सामान्यीकरण ब्रांचिंग और विलय को सामान्य रूप से बहुत आसान बना देता है।
ध्यान दें, कि Git में, संशोधन किसी भी शाखा में नहीं हैं। वे बस हैं और शाखाओं में उन्हें शामिल किया गया है। लेकिन एक बार जब शाखा का विलय हो जाता है, या मृत गली साबित होती है, तो आप इसे इंगित करने वाले "रेफ" को हटा सकते हैं और इसके बारे में पूरी तरह से भूल सकते हैं (यदि आप पुराने परीक्षणों को छोड़ देते हैं, तो वे अंततः कचरा-एकत्र हो जाएंगे git gc)। यह आपको पुराने प्रयोगों में दलदल से बचने में मदद करता है, किसी को याद नहीं है कि वे अब क्या कर रहे थे।
Git को उसी डेटा के 3D दृश्य के रूप में देखें, जिसे आप SVN में 2D में देखते हैं - यानी SVN के साथ आप अपनी जड़ को शाखा देते हैं और यह एक कॉपी के रूप में दिखाई देता है जिसे ट्री में एक नए फ़ोल्डर के रूप में दिखाया गया है। गिट के साथ, जब आप शाखा करते हैं तो यह आपके मौजूदा पेड़ की "परत" के रूप में दिखाई गई एक प्रति के रूप में दिखाई देती है। एक बार जब आप महसूस करते हैं कि इसके अंतर को समझना बहुत आसान है।
एसवीएन के साथ आप अभी भी उसी तरह से काम कर सकते हैं जैसे कि गिट - शाखाओं के बीच स्विच, कोडबेस के सिंगल व्यू को ब्रांच्ड व्यू से बदल देगा, यह लागू होता है चाहे आप svn स्विच या गिट चेकआउट का उपयोग करें।
जाहिर है आप अपने फ़ोल्डर स्थान के लिए शाखा की जाँच करके एसवीएन में एक शाखा की एक प्रति प्राप्त कर सकते हैं, जो आपके डिस्क पर एक अलग स्थान पर गिट रेपो को क्लोन करने के समान है।
एक ही टैग पर लागू होता है - आप एक गिट संशोधन को लेबल कर सकते हैं, या आप एक रिलीज के लिए एक शाखा बना सकते हैं। एसवीएन टैग शाखाओं के समान होते हैं, इसका एकमात्र कन्वेंशन जिसे वे 'टैग' कहते हैं। आप एक रिलीज़ का भी स्नैपशॉट प्राप्त करने के लिए एक SVN रेपो के लेबल (अच्छी तरह से, संशोधन संख्या को रिकॉर्ड कर सकते हैं)।
Git और svn के बीच अंतर अधिक है कि चेकइन और चेकआउट कैसे होते हैं, स्रोत नियंत्रण के मूल सिद्धांतों के साथ नहीं। कोड का दृश्य भिन्न हो सकता है (आप कोड ट्री का एक भी दृश्य कभी नहीं देख सकते हैं जिसमें गिट में शाखाएं शामिल हैं, और आप SVN में एक आंशिक रिपॉजिटरी शाखा कर सकते हैं, लेकिन ये अंततः मामूली अंतर हैं)