आप कई गिट रिपॉजिटरी कैसे व्यवस्थित करते हैं, ताकि सभी को एक साथ बैकअप दिया जाए?

Question

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

अब, मेरे पास गिट रिपॉजिटरी का एक गुच्छा है, विभिन्न परियोजनाओं के लिए, जिनमें से कई गिटबब पर हैं। मेरे पास SVN रिपॉजिटरी भी है जिसका मैंने उल्लेख किया है, git-svn कमांड के माध्यम से आयात किया गया है।

मूल रूप से, मुझे अपने सभी कोड (न केवल प्रोजेक्ट, बल्कि यादृच्छिक स्निपेट और स्क्रिप्ट्स, कुछ चीजें जैसे कि मेरा सीवी, लेख जो मैंने लिखे हैं, वेबसाइटें और इतने पर) हैं, एक बड़ी रिपॉजिटरी में मैं आसानी से रिमोट पर क्लोन कर सकता हूं। बैकअप के रूप में मशीनें, या मेमोरी-स्टिक्स / हार्डड्राइव।

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

मैं git सबमॉड्यूल सिस्टम का उपयोग कर सकता हूं , लेकिन यह अभिनय नहीं करता है कि मैं यह कैसे चाहता हूं (सबमॉड्यूल अन्य रिपॉजिटरी के संकेत हैं, और वास्तव में वास्तविक कोड नहीं है, इसलिए यह बैकअप के लिए बेकार है)

वर्तमान में मेरे पास git-repos का एक फ़ोल्डर है (उदाहरण के लिए, ~ / code_projects / proj1 / .it / ~ / code_projects / proj2 / .git /), और उसके बाद proj1 में परिवर्तन करने के बाद मैं करता हूँ git push github, फिर मैं फ़ाइलों को कॉपी करता हूँ ~ /। दस्तावेज़ / कोड / अजगर / परियोजनाएं / proj1 / और एक ही काम करते हैं (व्यक्तिगत प्रत्यावर्तन में कई लोगों के बजाय)। फिर करते हैं git push backupdrive1, git push mymemorystickआदि

तो, सवाल: आपके व्यक्तिगत कोड और git रिपॉजिटरी के साथ प्रोजेक्ट कैसे करते हैं, और उन्हें सिंक और बैक-अप रखते हैं?

Answer 1

मैं दिए गए गिट रिपॉजिटरी में असंबंधित डेटा डालने के खिलाफ दृढ़ता से सलाह दूंगा। नए रिपॉजिटरी बनाने का ओवरहेड काफी कम है, और यह एक ऐसी विशेषता है जो विभिन्न वंशों को पूरी तरह से अलग रखना संभव बनाता है।

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

एक समाधान यह है कि हर परियोजना / पैकेज / आदि को रखा जाए। अपने स्वयं के नंगे भंडार के रूप में (अर्थात, बिना काम के पेड़) एक धन्य पदानुक्रम के तहत, जैसे:

/repos/a.git
/repos/b.git
/repos/c.git

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

svn checkout   --> git clone
svn update     --> git pull
svn commit     --> git push

कई पार्टियों के बीच तालमेल बनाने में आसानी के लिए, आपके पास प्रत्येक कार्य क्लोन में कई रीमोट हो सकते हैं:

$ cd ~/dev
$ git clone /repos/foo.git       # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

फिर आप स्थानीय स्तर पर प्रत्येक "स्रोत" से काम कर सकते हैं और खींच सकते हैं, और फिर इनमें से प्रत्येक को हटा सकते हैं ("बैकअप") जब आप किसी चीज़ के साथ तैयार होते हैं (ध्यान दें कि कैसे एक ही हिट और इतिहास को धक्का देता है) प्रत्येक में से एक!):

$ for remote in origin github memorystick; do git push $remote; done

मौजूदा कार्यशील रिपॉजिटरी ~/dev/foo को ऐसे नंगे भंडार में बदलने का सबसे आसान तरीका है :

$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git

जो कि ज्यादातर एक के बराबर है svn import- लेकिन मौजूदा, "स्थानीय" इतिहास को दूर नहीं फेंकता है।

नोट: सबमॉड्यूल्स साझा संबंधित वंशावली को शामिल करने के लिए एक तंत्र है , इसलिए मैं वास्तव में उन्हें उस समस्या के लिए एक उपयुक्त उपकरण नहीं मानूंगा जिसे आप हल करने की कोशिश कर रहे हैं।

Comments

तथ्य यह है कि मैं बहुत से अलग-अलग रिपॉजिटरी के साथ समाप्त हो रहा हूं और उन सभी को प्रबंधित करने में मदद करने के लिए सरल स्क्रिप्ट लिख रहा हूं जिससे मुझे लगता है कि गिट में कुछ गायब है। मैं अभी तय नहीं कर सकता कि यह क्या है या इसके बारे में क्या करना है।

— डोनगर

ठीक है, क्या आप बहुत सारी अलग-अलग परियोजनाओं का प्रबंधन करते हैं? परियोजनाओं और रिपॉजिटरी के बीच एक-से-एक संबंध एक वितरित दुनिया में उचित लगता है, लेकिन मैं अभी भी बैकअप और प्रशासन में आसानी के लिए एक सामान्य निर्देशिका ट्री में नंगे रिपॉजिटरी की व्यवस्था करूंगा। (दूसरे शब्दों में, Git / Hg / Bzr आपको प्रोजेक्ट कार्यों से प्रशासन को अलग करने के लिए मजबूर करता है, जबकि अधिकांश SVN वर्कफ़्लो दो को भ्रमित करता है; यह अब आम है कि लोग GitHub या ऐसे अन्य प्रदाताओं को प्रशासनिक भाग सौंपते हैं)

— डेमियन डिडरेन

यह विचार केवल तभी समझ में आता है जब आप अपनी खुद की परियोजनाओं की मेजबानी करते हैं और / या वे सभी खुले स्रोत होते हैं। अन्यथा आपको

— जीथब की

इसके बजाय "रिमोट इन ओरिजिनल जीथब मेमोरीस्टिक; जिट पुश फॉर $ रिमोट; किया", एक विशेष रिमोट को एक सिंगल कमांड के साथ पुश करने के लिए कई रिमोट को कॉन्फ़िगर कर सकते हैं: stackoverflow.com/questions/36862/… । (कुछ मामलों में अधिक सुविधाजनक हो सकता है।)

— इम्ज़ - इवान ज़खरीशेव

मुझे लगता है कि लापता चीज एक ऐसा तरीका है जो गिट इसे वस्तुओं को अलग-अलग करके रख सकता है ताकि एक "रिपॉजिटरी" को अलग-अलग सिंक्रनाइज़ किया जा सके, हालांकि अलग करने योग्य इकाइयाँ (व्यक्तिगत रूप से बाकी के बिना डाउनलोड की गई) इस तरह से कि लोग विशिष्ट पर काम कर सकें इसके बाकी हिस्सों के बारे में जाने बिना सबसेट।

— पेटर्क

Answer 2

मैं डेमियन के जवाब में जोड़ना चाहता हूं जहां वह अनुशंसा करता है:

$ for remote in origin github memorystick; do git push $remote; done

आप 1 कमांड के साथ सभी व्यक्तिगत वास्तविक रिमोट को पुश करने के लिए एक विशेष रिमोट सेट कर सकते हैं; मैंने इसे http://marc.info/?l=git&m=116231242118202&w=2 पर पाया :

तो "गिट पुश" के लिए (जहां यह कई बार एक ही शाखाओं को पुश करने के लिए समझ में आता है), आप वास्तव में वही कर सकते हैं जो मैं करता हूं:

• .it / config में शामिल है:

  [remote "all"]
  url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
  url = login.osdl.org:linux-2.6.git
  

• और अब उन दोनों दूरस्थ रिपॉजिटरी git push all masterमें "मास्टर" शाखा को आगे बढ़ाएगा।
  

आप निर्देश का उपयोग करके खुद को दो बार यूआरएल टाइप करने से भी बचा सकते हैं:

[url "<actual url base>"]
    insteadOf = <other url base>

Answer 3

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

./bin/            # prepended to $PATH
./lib/            # prepended to $LD_LIBRARY_PATH
./lib/python/     # prepended to $PYTHONPATH
./setup_env.bash  # sets up the environment

अब अंदर / बिन और / lib वहाँ कई परियोजनाओं और उनके इसी पुस्तकालय हैं। मुझे पता है कि यह एक मानक परियोजना नहीं है, लेकिन मेरे समूह के किसी और व्यक्ति के लिए रेपो की जांच करना, 'setup_env.bash' स्क्रिप्ट को चलाना बहुत आसान है और स्थानीय रूप से सभी परियोजनाओं के संस्करण की तारीख तक सबसे अधिक है चेक आउट। उन्हें / usr / bin या / usr / lib को स्थापित करने / अद्यतन करने के बारे में चिंता करने की आवश्यकता नहीं है और यह प्रत्येक चेकआउट के लिए कई चेकआउट और एक बहुत स्थानीय वातावरण रखना आसान रखता है। कोई व्यक्ति केवल संपूर्ण रिपॉजिटरी को rm कर सकता है और किसी प्रोग्राम को अनइंस्टॉल करने की चिंता नहीं कर सकता है।

यह हमारे लिए ठीक काम कर रहा है, और मुझे यकीन नहीं है कि हम इसे बदल देंगे। इसके साथ समस्या यह है कि इस एक बड़े भंडार में कई परियोजनाएं हैं। क्या इस तरह का वातावरण बनाने और अपने स्वयं के भंडार में परियोजनाओं को तोड़ने का एक मानक / Hg / bzr मानक तरीका है?

Answer 4

, मैंने अभी तक जीआईटी रिपॉजिटरी को नेस्ट करने की कोशिश नहीं की है क्योंकि मैं उस स्थिति में नहीं चला हूं जहां मुझे जरूरत है। जैसा कि मैंने #it ​​चैनल पर पढ़ा है कि git रिपॉजिटरी को नेस्ट करके भ्रमित होने लगता है, यानी आप एक git रिपॉजिटरी के अंदर git-init की कोशिश कर रहे हैं। नेस्टेड git संरचना को प्रबंधित करने का एकमात्र तरीका git-submoduleया तो उपयोग करना है या Android की repoउपयोगिता है।

उस बैकअप ज़िम्मेदारी के लिए, जिसका आप वर्णन कर रहे हैं, मैं कहता हूं कि इसे प्रत्यायोजित करें ... मेरे लिए मैं आमतौर पर प्रत्येक प्रोजेक्ट के लिए "मूल" रिपॉजिटरी को काम पर एक नेटवर्क ड्राइव पर रखता हूं, जो उनकी बैकअप रणनीति द्वारा आईटी-टेक द्वारा नियमित रूप से समर्थित है। चुनाव। यह सरल है और मुझे इसके बारे में चिंता करने की आवश्यकता नहीं है। ;)

Answer 5

एक ही बार में अपने कई Git repos के प्रबंधन के लिए mr का उपयोग करने के बारे में क्या :

Mr (1) कमांड रिपॉजिटरी के सेट पर अन्य क्रियाओं को चेकआउट, अपडेट या प्रदर्शन कर सकता है जैसे कि वे एक संयुक्त रेस्पिरेटरी थे। यह तोड़फोड़, git, cv, मर्क्यूरियल, bzr, डार्क्स, cvs, vcsh, जीवाश्म और सत्यता रिपॉजिटरी के किसी भी संयोजन का समर्थन करता है, और अन्य संशोधन नियंत्रण प्रणालियों के लिए समर्थन आसानी से जोड़ा जा सकता है। [...]

यह सरल शेल स्क्रिप्टिंग के माध्यम से अत्यंत विन्यास योग्य है। चीजों के कुछ उदाहरण इसमें शामिल हो सकते हैं:

[...]

• गिट रिपॉजिटरी को अपडेट करते समय, दो अलग-अलग अपस्ट्रीम से खींचें और दोनों को एक साथ मर्ज करें।
• समानांतर में कई रिपॉजिटरी अपडेट चलाएं, अपडेट प्रक्रिया को बहुत तेज करें।
• याद रखें कि ऐसे कार्य जो लैपटॉप के ऑफ़लाइन होने के कारण विफल हुए, इसलिए ऑनलाइन वापस आने पर उन्हें वापस लिया जा सकता है।

Answer 6

नेस्टेड जीआईटी रिपॉजिट करने के लिए एक और तरीका है, लेकिन यह उस समस्या को हल नहीं करता है जो आप कर रहे हैं। फिर भी, उन अन्य लोगों के लिए जो इस समाधान की तलाश में हैं:

शीर्ष स्तर के git रेपो में केवल .गितिग्नोर को नेस्टेड git रेपो वाले फ़ोल्डर को छिपाते हैं। इससे दो अलग-अलग (लेकिन नेस्टेड!) Git repos होना आसान हो जाता है।