🔰 💇🏽 🍋 एसवीएन से गिट तक एक परियोजना को आगे बढ़ाना 🎾 🧔🏼 🤑

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

1. केंद्रीय भंडार के लिए सर्वर

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

यहाँ चुनाव विशेष रूप से महान नहीं है - गिटोसिस या गिटोलिट। चूंकि कई वर्षों तक गिटोसिस का विकास नहीं हुआ है, इसलिए विकल्प गिटोलिट पर गिर गया।

1.1। जिओलाइट स्थापना

हमने सर्वर पर gitolite 3.03 डाला:

$ emerge gitolite

यह एक git यूजर बनाता है जो भविष्य के सभी रिपॉजिटरी का मालिक होगा।

1.2। प्रारंभिक सेटअप

अब हमें रिपॉजिटरी (gitolite स्टोर की सभी सेटिंग git रिपॉजिटरी में एक्सेस करने के लिए) और सार्वजनिक स्थान पर सार्वजनिक कुंजी को सहेजने के लिए rsa key जेनरेट करनी होगी:

 $ ssh-keygen -t rsa $ cp ~/.ssh/id_rsa.pub /tmp/admin.pub

उसके बाद, आप वास्तव में गिटोलिट को इनिशियलाइज़ कर सकते हैं:

 $ su git $ cd $ mkdir -p bin $ gitolite/install -ln $ gitolite setup -pk /tmp/admin.pub

1.3। एक परियोजना के लिए एक भंडार का निर्माण

सर्वर स्थापित है, हम अपने उपयोगकर्ता पर लौटते हैं और कॉन्फ़िगरेशन के साथ हमारी रिपॉजिटरी को क्लोन करते हैं:

 $ cd $ git clone git@server:gitolite-admin.git

इसके बाद, सर्वर उस सर्वर का होस्टनाम होता है जिस पर जिओलाइट स्थापित होता है और रिपॉजिटरी संग्रहित होता है।

दिखाई गई gitolite-admin / conf / gitolite.conf फ़ाइल खोलें और अंत में हमारी परियोजना के लिए रिपॉजिटरी विवरण जोड़ें (केवल एक उपयोगकर्ता के साथ अब तक):

 repo project RW+ = javer

उसके बाद हम अपने परिवर्तनों को सहेजते हैं। गिटोलिट-एडमिन होने के नाते, हम निष्पादित करते हैं:

 $ git add . $ git commit -am "Repository for project added" $ git push origin master

gitolite स्वचालित रूप से उन सभी रिपॉजिटरी को इनिशियलाइज़ कर देगा जो कि कॉन्फिगर में वर्णित हैं और अभी तक मौजूद नहीं हैं।

यही है, गिटोलिट स्थापित है और शुरू में कॉन्फ़िगर किया गया है, हमारी परियोजना के लिए एक भंडार बनाया गया है, आप आगे बढ़ सकते हैं।

2. एसवीएन से आयात परियोजना

सीधे एसवीएन रिपॉजिटरी को गिट में परिवर्तित करना कमांड का उपयोग करके किया जाता है

 $ git svn clone

इसके लिए, जीआईटी को पेरल सपोर्ट के साथ संकलित किया जाना चाहिए।

2.1। ऑडिट परिभाषा शुरू करें

हमारा प्रोजेक्ट प्रोजेक्ट SVN रिपॉजिटरी में कई अन्य परियोजनाओं के साथ स्थित है। चूँकि संशोधन संख्याएँ संपूर्ण रिपॉजिटरी के माध्यम से क्रॉस-कटिंग होती हैं, इसलिए हम svn में पहली कमिट लॉग करते हैं, जो हमारे प्रोजेक्ट की चिंता करता है, और इसे याद रखें। आयात में तेजी लाने के लिए यह आवश्यक है ताकि पहले से शुरू होने वाले सभी संशोधन स्कैन न हों। हमारे मामले में, यह संशोधन 19815 है, इसलिए विकल्प ऊपर दिए गए आदेश में जोड़ा गया है:

 -r19815:HEAD

2.2। एसवीएन यूजर्स को गिट यूजर्स से मिलाना

अगला, हमें भविष्य के Git उपयोगकर्ताओं के साथ SVN उपयोगकर्ताओं का मिलान करने की आवश्यकता है ताकि आयात के दौरान उन्हें सफलतापूर्वक बदल दिया जाए। ऐसा करने के लिए, कहीं न कहीं हम निम्नलिखित सामग्री के साथ लेखक फ़ाइल बनाते हैं:

 javer = javer <javer@domain.tld> developer1 = developer1 <developer1@domain.tld> ...

जहाँ user@domain.tld git उपयोगकर्ता का ई-मेल है (git में, प्रत्येक उपयोगकर्ता नाम और ईमेल से पहचाना जाता है)।

तदनुसार, विकल्प को आयात कमांड में जोड़ा जाता है:

 --authors-file=/path/to/authors

2.3। अनावश्यक फ़ाइलों का बहिष्कार

हम और आगे जा रहे हैं। हमारी परियोजना में, बड़ी बाइनरी फ़ाइलों के यादृच्छिक कमिट थे, जिनकी हमें नई रिपॉजिटरी में आवश्यकता नहीं है। उन्हें आयात करते समय, आप विकल्प को छोड़ सकते हैं:

 --ignore-paths="\.(avi|mov)$"

2.4। अतिरिक्त विकल्प

हमें SVN में एक उपयोगकर्ता की आवश्यकता है, जिसकी ओर से रिपॉजिटरी तक पहुंच बनाई जाएगी:

 --username javer

हम एक और विकल्प जोड़ते हैं - कोई-मेटाडेटा, जिसकी आवश्यकता है ताकि प्रत्येक टिप्पणी में कमिट लॉग में: फॉर्म के कोई जोड़ न हों:

 git-svn-id: svn://svn.domain.tld/repo/project/trunk@19815 e13dc095-444b-fa4e-8f24-06838a8318a5

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

2.5। एसवीएन रिपॉजिटरी से एक परियोजना का क्लोनिंग

यह सब एक साथ रखना और चलाना:

 $ cd $ mkdir project && cd project $ git svn clone -r19815:HEAD --authors-file=/path/to/authors --ignore-paths="\.(avi|mov)$" --username javer --no-metadata svn://svn.domain.tld/repo/project/trunk .

जहां svn: //svn.domain.tld/repo/project/trunk SVN रिपॉजिटरी में हमारी परियोजना का ट्रंक पता है।

क्लोनिंग प्रक्रिया शुरू होती है, जिसकी अवधि कमिट की संख्या और उनकी मात्रा पर निर्भर करती है। हमारे मामले में, लगभग 4.5 हजार कमिट थे, और उन्हें क्लोन करने में लगभग दो घंटे लगे।

2.6। अधिक अनावश्यक फ़ाइलों और निर्देशिकाओं का बहिष्करण

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

 $ git filter-branch --tree-filter 'rm -rf unneeded_directory' -f HEAD

यह प्रक्रिया भी काफी लंबी है, क्योंकि प्रत्येक प्रतिबद्ध की व्यक्तिगत रूप से समीक्षा की जाती है, और हमारे मामले में प्रत्येक प्रतिबद्ध के लिए लगभग 1 सेकंड का समय लगता है।

2.7। खाली कमिट्स निकालना

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

 $ git filter-branch --commit-filter 'git_commit_non_empty_tree "$@"' HEAD

इस ऑपरेशन में ट्री-फिल्टर के समान समय लगता है।

2.8। खाली निर्देशिका और svn: उपेक्षा

अगला, हमें पूर्व svn को बदलने की आवश्यकता है: नए .gitignore पर ध्यान न दें। यह इस प्रकार किया जाता है:

 $ git svn create-ignore

यह मत भूलो कि git केवल फ़ाइलों के बारे में निर्देशिकाओं के बारे में जानकारी संग्रहीत नहीं करता है, इसलिए सभी खाली निर्देशिकाओं में आपको एक खाली .gitignore फ़ाइल बनाने की आवश्यकता है, और फिर इन सभी फ़ाइलों को प्रतिबद्ध करें:

 $ git add . $ git commit -am "Added .gitignore"

2.9। SVN उल्लेख हटाएं

चूंकि हमारा प्रोजेक्ट पूरी तरह से SVN से Git में जा रहा है, इसलिए हम SVN के सभी संदर्भ हटा देते हैं:

 $ git branch -rd git-svn $ git config --remove-section svn-remote.svn $ git config --remove-section svn $ rm -rf .git/svn

2.10। svn: बाहरी

हमारी परियोजना में, कुछ सिम्फनी प्लगइन्स, दोनों कस्टम और सार्वजनिक, svn: externals के माध्यम से जुड़े थे। चूंकि गिट में ऐसा कोई तंत्र नहीं है, इसलिए हम इसके लिए सबमॉड्यूल का उपयोग करेंगे। सार्वजनिक प्लगइन्स के साथ यह आसान है:

 $ git submodule add git://github.com/propelorm/sfPropelORMPlugin.git plugins/sfPropelORMPlugin $ git submodule add git://github.com/n1k0/npAssetsOptimizerPlugin.git plugins/npAssetsOptimizerPlugin

यह आपके प्लगइन्स के साथ थोड़ा अधिक जटिल है - उनके लिए आपको ऊपर वर्णित एक के समान अलग रिपॉजिटरी बनाने की आवश्यकता है, और फिर उन्हें उसी तरह हमारी परियोजना से कनेक्ट करें:

 $ git submodule add git@server:customPlugin.git plugins/customPlugin

सबमोड्यूल्स को जोड़ने के बाद, उन्हें प्रोजेक्ट डायरेक्टरी में क्लोन किया जाना चाहिए:

 $ git submodule update --init --recursive $ git commit -am "Added submodules: sfPropelORMPlugin, npAssetsOptimizerPlugin, customPlugin"

2.11। सर्वर के लिए प्रोजेक्ट की स्थानीय प्रतिलिपि भेज रहा है

इस ऑपरेशन को गति देने के लिए हमारी परियोजना को सर्वर पर भेजने से पहले, हम इसे अनुकूलित करते हैं:

 $ git gc

हम अपने नए भंडार को परियोजना से जोड़ते हैं:

 $ git remote add origin git@server:project.git

और अंत में, सर्वर पर परियोजना की स्थानीय प्रतिलिपि भरें:

 $ git push origin master

2.12। भविष्य के सबमॉड्यूल्स अपडेट

चूंकि, svn के विपरीत: बाह्य, स्थानीय प्रतिलिपि का एक सरल अद्यतन के साथ एक विशिष्ट प्रतिबद्ध करने के लिए प्रत्येक सबमॉड्यूल अंक

 $ git pull

सबमॉड्यूल की सामग्री को अपडेट नहीं किया जाएगा। उनका अद्यतन निम्नानुसार है:

 $ git submodule update

मामले में परिवर्तन थे:

 $ git submodule foreach git pull $ git commit -am "Updated submodules"

3. रिपॉजिटरी परमिशन सेट करना

3.1। कस्टम कुंजी

चूंकि दूरस्थ गिट रिपॉजिटरी तक पहुंच ssh के माध्यम से है, अब प्रत्येक डेवलपर को अपनी मशीन पर एक rsa कुंजी उत्पन्न करनी होगी।

3.1.1। लिनक्स / यूनिक्स

विंडोज पर लिनक्स / यूनिक्स या गिट बैश के मामले में इस तरह किया जाता है:

 $ ssh-keygen -t rsa

उसके बाद, प्राप्त सार्वजनिक कुंजी ~ / .ssh / id_rsa.pub रिपॉजिटरी एडमिनिस्ट्रेटर को दी जाती है।

3.1.2। विंडोज

विंडोज के लिए, आप पुट्टीजेन का भी उपयोग कर सकते हैं, जिसे यहां डाउनलोड किया जा सकता है: पुट्टीजेन ।

हम पोटीन शुरू करते हैं, उत्पन्न पर क्लिक करें, कुंजी उत्पन्न होने तक माउस को खिड़की पर खींचें, फिर टिप्पणी क्षेत्र में इंगित करें कि यह कुंजी क्या है, यदि आवश्यक हो तो कुंजी एक्सेस पासवर्ड दर्ज करें। उसके बाद, सार्वजनिक कुंजी फ़ील्ड की सामग्री को कॉपी करें, इसे user.pub फ़ाइल में सहेजें और इसे रिपॉजिटरी व्यवस्थापक को स्थानांतरित करें।

फिर हम निजी कुंजी सहेजें पर क्लिक करते हैं और इस कुंजी को आगे उपयोग के लिए एकांत स्थान पर सहेजते हैं, उदाहरण के लिए, TortoiseGit में।

इसके अलावा, रूपांतरण मेनू में, निर्यात OpenSSH कुंजी चुनें और इसे C: \ Users \ERNERNAME \ .ssh \ id_rsa नामक फ़ाइल में सहेजें, जहाँ USERNAME सिस्टम में आपके उपयोगकर्ता का नाम है। कमांड लाइन से गिट का उपयोग करते समय हमें इस कुंजी की आवश्यकता होगी।

3.2। अनुमतियाँ सेट करना

पिछले चरण में प्राप्त उपयोगकर्ता सार्वजनिक कुंजी को USERNAME.pub के नाम वाली फाइलों में ~ / gitolite-admin / keydir / निर्देशिका में व्यवस्थापक रिपॉजिटरी में रखा जाता है, जहां USERNAME उपयोगकर्ता नाम है।

चूंकि जिओलाइट में बहुत सारे अनुकूलन विकल्प हैं, इसलिए हम अपनी परियोजना के भंडार तक पहुंच अधिकारों को कॉन्फ़िगर करने के लिए उनका उपयोग करते हैं। ऐसा करने के लिए, फ़ाइल को संपादित करें ~ / gitolite-admin / conf / gitolite.conf और इसे फ़ॉर्म में लाएं:

@owners = javer
@project_developers = user1 user2 user3
@deploy = root@production

repo project
- master$ = @project_developers
- refs/tags = @project_developers
RW+ = @project_developers @owners
R = @deploy

यह हमें मालिकों के उपयोगकर्ता समूह के लिए पूर्ण पहुँच प्रदान करता है। Project_developers समूह के लिए, मास्टर शाखा को लिखने और टैग बनाने के अपवाद के साथ, अपनी शाखाएं बनाने की क्षमता के साथ पूर्ण पहुंच भी है। तैनात समूह के लिए, जिसका उपयोग उत्पादन में तैनाती के लिए किया जाता है, हम केवल-पढ़ने की अनुमति देते हैं।

अंत में, सभी परिवर्तनों को सहेजना न भूलें:

 $ git add . $ git commit -am "New users for project: user1, user2, user3..." $ git push origin master

4. डेवलपर्स की मशीनों पर स्थापना और विन्यास

सर्वर भाग पूरी तरह से तैयार है, अब यह विकास मशीनों पर गिट क्लाइंट को स्थापित और कॉन्फ़िगर करने के लिए रहता है।

4.1। लिनक्स / यूनिक्स

यहां सब कुछ सरल है - हम अपने पसंदीदा पैकेज मैनेजर की मदद से गिट स्थापित करते हैं।

स्थापना के बाद, अपना नाम और ई-मेल निर्दिष्ट करना न भूलें, एसवीएन से आयात करते समय उपयोग किए जाने वाले समान:

 $ git config --global user.name "javer" $ git config --global user.email "user@domain.tld"

4.2। विंडोज

यहां कई अलग-अलग ग्राहक हैं, अब तक मैं टोर्टोइसगिट पर बस गया हूं।

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

उसके बाद, TortoiseGit को स्वयं इंस्टॉल करें। मैं नवीनतम स्थिर संस्करण स्थापित करने की सलाह देता हूं, लेकिन रात्रिकालीन निर्माण नहीं।

अब TortoiseGit सेटिंग्स पर जाएं (किसी भी निर्देशिका पर राइट-क्लिक करें और TortoiseGit-> सेटिंग्स), वहां Git सेक्शन ढूंढें और दाईं ओर उपयोगकर्ता जानकारी ब्लॉक में अपना नाम और ई-मेल दर्ज करें।

5. चाल पूरी हो गई है। काम पर लगना

यही है, एसवीएन से गिट तक जाने की प्रक्रिया पूरी हो गई है।

प्रत्येक डेवलपर अपनी कार पर एक प्रोजेक्ट क्लोन करता है और उसके साथ काम करना शुरू कर देता है।

मैं डेवलपर्स को इन लेखों को पढ़ने की सलाह दूंगा:

एसवीएन से गिट तक एक परियोजना को आगे बढ़ाना