खोज…
टिप्पणियों
क्लोनिंग वास्तव में बड़ी SVN रिपॉजिटरी
यदि आप SVN रेपो इतिहास वास्तव में बहुत बड़ा है तो इस ऑपरेशन में घंटों लग सकते हैं, क्योंकि git-svn को SVN रेपो के पूरे इतिहास के पुनर्निर्माण की आवश्यकता है। सौभाग्य से आपको केवल एसवीएन रेपो को एक बार क्लोन करना होगा; किसी अन्य गिट रिपॉजिटरी के साथ आप अन्य सहयोगियों के लिए रेपो फ़ोल्डर को कॉपी कर सकते हैं। कई कंप्यूटरों में फोल्डर को कॉपी करने से यह तेज हो जाएगा कि स्क्रैच से सिर्फ बड़े SVN रिपोज को क्लोन करना है।
कमिट्स और SHA1 के बारे में
कमांड git svn dcommit का उपयोग करते समय आपके स्थानीय गिट को फिर से लिखा जाएगा। यह कमांड एसवीएन सर्वर में बनाए गए एसवीएन संशोधन का संदर्भ देते हुए, कमिट के संदेश में एक पाठ जोड़ देगा, जो बहुत उपयोगी है। हालाँकि, एक नए पाठ को जोड़ने के लिए एक मौजूदा प्रतिबद्ध संदेश को संशोधित करने की आवश्यकता होती है जो वास्तव में नहीं किया जा सकता है: git commits अयोग्य हैं। समाधान एक ही सामग्री और नए संदेश के साथ एक नई प्रतिबद्ध बनाता है, लेकिन यह तकनीकी रूप से वैसे भी एक नई प्रतिबद्धता है (यानी git कमिट का SHA1 बदल जाएगा)
जैसे git-svn के लिए बनाए गए git commits स्थानीय हैं, git commits के लिए SHA1 id प्रत्येक git रिपॉजिटरी के बीच अलग होती हैं! इसका मतलब यह है कि आप किसी अन्य व्यक्ति से कमिट करने के लिए SHA1 का उपयोग नहीं कर सकते क्योंकि उसी कमिट में प्रत्येक स्थानीय git रिपॉजिटरी में एक अलग SHA1 होगा। जब आप रिपॉजिटरी की विभिन्न प्रतियों के बीच एक कमिट का संदर्भ लेना चाहते हैं तो आपको एसवीएन सर्वर पर धकेलने पर प्रतिबद्ध संदेश में संलग्न एसवीएन संशोधन संख्या पर भरोसा करना होगा।
आप स्थानीय परिचालनों के लिए SHA1 का उपयोग कर सकते हैं, हालांकि (एक विशिष्ट प्रतिबद्धता, चेरी-पिक्स और रीसेट, आदि को दिखा / भिन्न कर सकते हैं)
समस्या निवारण
git svn rebase कमांड एक चेकसम मिसमैच एरर जारी करता है
कमांड git svn rebase इस के समान त्रुटि फेंकता है:
Checksum mismatch: <path_to_file> <some_kind_of_sha1>
expected: <checksum_number_1>
got: <checksum_number_2>
इस समस्या का समाधान svn को पुनरीक्षण के लिए रीसेट किया जाता है जब परेशान फ़ाइल को अंतिम बार संशोधित किया गया था, और एक git svn प्राप्त करें ताकि SVN इतिहास बहाल हो जाए। SVN रीसेट करने के लिए आदेश हैं:
- git लॉग -1 -
<path_to_file>(प्रतिबद्ध संदेश में दिखाई देने वाले SVN संशोधन संख्या की प्रतिलिपि बनाएँ) - git svn रीसेट
<revision_number> - git svn fetch
आपको एसवीएन से डेटा को फिर से धक्का / खींचने में सक्षम होना चाहिए
फ़ाइल तब नहीं मिली जब आप SVN से लाने या खींचने का प्रयास करते हैं, आपको इसके समान त्रुटि मिलती है
<file_path> was not found in commit <hash>
इसका मतलब यह है कि एसवीएन में एक संशोधन एक फाइल को संशोधित करने की कोशिश कर रहा है जो किसी कारण से आपकी स्थानीय प्रतिलिपि में मौजूद नहीं है। इस त्रुटि से छुटकारा पाने का सबसे अच्छा तरीका उस फाइल के पथ की अनदेखी करने वाला एक बल है और यह नवीनतम एसवीएन संशोधन में अपनी स्थिति को अद्यतन करेगा:
-
git svn fetch --ignore-paths <file_path>
एसवीएन रिपॉजिटरी की क्लोनिंग
आपको कमांड के साथ रिपॉजिटरी की एक नई स्थानीय प्रतिलिपि बनाने की आवश्यकता है
git svn clone SVN_REPO_ROOT_URL [DEST_FOLDER_PATH] -T TRUNK_REPO_PATH -t TAGS_REPO_PATH -b BRANCHES_REPO_PATH
यदि आपका SVN रिपॉजिटरी मानक लेआउट (ट्रंक, ब्रांच, टैग फ़ोल्डर) का अनुसरण करता है तो आप कुछ टाइपिंग को बचा सकते हैं:
git svn clone -s SVN_REPO_ROOT_URL [DEST_FOLDER_PATH]
git svn clone एक-एक करके प्रत्येक SVN संशोधन की जाँच करता है, और इतिहास को फिर से बनाने के लिए आपके स्थानीय रिपॉजिटरी में एक git कमिट करता है। यदि SVN रिपॉजिटरी में बहुत कमिट हैं तो इसमें कुछ समय लगेगा।
जब कमांड समाप्त हो जाता है, तो आपके पास स्थानीय शाखा के साथ पूर्ण विकसित गिट रिपॉजिटरी होगी जिसे मास्टर कहा जाता है जो एसवीएन रिपॉजिटरी में ट्रंक शाखा को ट्रैक करता है।
एसवीएन से नवीनतम परिवर्तन प्राप्त करना
git pull बराबर कमांड है
git svn rebase
यह SVN रिपॉजिटरी से सभी परिवर्तनों को पुनर्प्राप्त करता है और उन्हें आपकी वर्तमान शाखा में आपके स्थानीय कमिट के शीर्ष पर लागू करता है।
आप कमांड का उपयोग भी कर सकते हैं
git svn fetch
एसवीएन रिपॉजिटरी से परिवर्तनों को प्राप्त करने और उन्हें अपनी स्थानीय मशीन पर लाने के लिए लेकिन उन्हें अपनी स्थानीय शाखा में लागू किए बिना।
एसवीएन में स्थानीय परिवर्तन लाना
आदेश
git svn dcommit
आपके प्रत्येक स्थानीय हिट के लिए SVN संशोधन का निर्माण करेगा। SVN के साथ के रूप में, आपका स्थानीय git इतिहास SVN रिपॉजिटरी में नवीनतम परिवर्तनों के साथ सिंक होना चाहिए, इसलिए यदि कमांड विफल रहता है, तो पहले git svn rebase करने का प्रयास करें।
स्थानीय स्तर पर काम करना
सामान्य git कमांड के साथ, सामान्य git रेपो के रूप में अपने स्थानीय git रिपॉजिटरी का उपयोग करें:
-
git add FILEऔरgit checkout -- FILEको स्टेज / अनस्टेज करने के लिए फाइल करें -
git commitअपने परिवर्तनों को बचाने के लिए। वे कमिट स्थानीय होंगे और एसवीएन रेपो के लिए "धकेल" नहीं होंगे, ठीक वैसे ही जैसे एक सामान्य गिट रिपॉजिटर्स में होते हैं। -
git stashऔरgit stash popstashes का उपयोग करने की अनुमति देता है -
git reset HEAD --hardअपने सभी स्थानीय परिवर्तनों को वापस लाएं -
git logरिपॉजिटरी में सभी इतिहास को एक्सेस करें -
git rebase -iताकि आप अपने स्थानीय इतिहास को स्वतंत्र रूप से लिख सकें -
git branchऔरgit checkoutस्थानीय शाखाएँ बनाने के लिए
जैसा कि git-svn प्रलेखन में कहा गया है कि "तोड़फोड़ एक प्रणाली है जो Git की तुलना में बहुत कम परिष्कृत है" इसलिए आप तोड़फोड़ सर्वर में इतिहास को गड़बड़ाने के बिना गिट की पूरी शक्ति का उपयोग नहीं कर सकते। सौभाग्य से नियम बहुत सरल हैं: इतिहास को रैखिक रखें
इसका मतलब है आप लगभग किसी भी Git आपरेशन कर सकते हैं: पुन: क्रम, शाखाओं बनाने को हटाने / / कुचलने कमिट, इतिहास चारों ओर ले जाने, हटाने कमिट, आदि कुछ भी लेकिन मर्ज के। यदि आपको स्थानीय शाखाओं के इतिहास को पुन: स्थापित करने की आवश्यकता है तो इसके बजाय git rebase उपयोग करें।
जब आप मर्ज करते हैं, तो एक मर्ज कमिट बन जाता है। मर्ज कमिट के बारे में विशेष बात यह है कि उनके दो माता-पिता हैं, और यह इतिहास को गैर-रैखिक बनाता है। गैर-रैखिक इतिहास एसवीएन को उस स्थिति में भ्रमित कर देगा, जब आप भंडार के लिए एक मर्ज को "धक्का" देते हैं।
हालांकि चिंता न करें: आप कुछ भी नहीं तोड़ेंगे यदि आप एसवीएन के लिए एक मर्ज मर्ज को "पुश" करते हैं । यदि आप ऐसा करते हैं, तो जब git मर्ज कमिट को svn सर्वर पर भेजा जाता है, तो इसमें उस मर्ज के सभी कमिट के सभी बदलाव शामिल होंगे, इसलिए आप उन कमिट्स के इतिहास को खो देंगे, लेकिन आपके कोड में बदलाव नहीं।
खाली फोल्डर को संभालना
git फ़ोल्डरों की अवधारणा को नहीं पहचानता है, यह सिर्फ फाइलों और उनके फाइलपथ के साथ काम करता है। इसका मतलब यह है कि गिट खाली फ़ोल्डर्स को ट्रैक नहीं करता है। एसवीएन, हालांकि, करता है। Git-svn का उपयोग करने का अर्थ है कि, डिफ़ॉल्ट रूप से, आप git वाले खाली फ़ोल्डरों को शामिल करने वाले किसी भी परिवर्तन को SVN के लिए प्रचारित नहीं करेंगे ।
--rmdir फ्लैग का उपयोग करते समय एक टिप्पणी जारी करने से यह समस्या ठीक हो जाती है, और यदि आपने स्थानीय रूप से इसके अंदर की अंतिम फ़ाइल को हटा दिया है, तो SVN में एक खाली फ़ोल्डर निकाल देता है:
git svn dcommit --rmdir
दुर्भाग्य से यह मौजूदा खाली फ़ोल्डरों को नहीं हटाता है : आपको इसे मैन्युअल रूप से करने की आवश्यकता है।
प्रत्येक बार जब आप एक डोकिटम करते हैं, या यदि आप एक गिट GUI टूल (जैसे SourceTree) का उपयोग कर रहे हैं, तो इसे चलाने के लिए ध्वज जोड़ने से बचने के लिए, आप इस व्यवहार को कमांड के साथ डिफ़ॉल्ट रूप से सेट कर सकते हैं:
git config --global svn.rmdir true
यह आपकी .gitconfig फ़ाइल को बदलता है और इन पंक्तियों को जोड़ता है:
[svn]
rmdir = true
एसवीएन के लिए सभी अनुपलब्ध फ़ाइलों और फ़ोल्डरों को खाली रखने के लिए git कमांड का उपयोग करें:
git clean -fd
कृपया ध्यान दें: पिछली कमांड सभी अनट्रैक की गई फ़ाइलों और खाली फ़ोल्डरों को हटा देगी, यहां तक कि उन पर भी नजर रखी जानी चाहिए जिन्हें SVN द्वारा ट्रैक किया जाना चाहिए! यदि आपको SVN द्वारा ट्रैक किए गए खाली फ़ोल्डरों को एग कमांड का उपयोग करने के लिए उत्पन्न करना है
git svn mkdirs
प्रथाओं में इसका मतलब है कि यदि आप अपने कार्यक्षेत्र को बिना फ़ाइलों और फ़ोल्डरों से साफ करना चाहते हैं, तो आपको हमेशा एसवीएन द्वारा ट्रैक किए गए खाली फ़ोल्डरों को फिर से बनाने के लिए दोनों कमांड का उपयोग करना चाहिए:
git clean -fd && git svn mkdirs