आप कई गिट भंडार कैसे व्यवस्थित करते हैं, ताकि उनमें से सभी का बैक अप लिया जा सके?

Question

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

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

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

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

मैं सकता है Git submodule प्रणाली का उपयोग, लेकिन यह काम नहीं करता है मैं कैसे चाहते हैं कि उसे भी (submodules अन्य खजाने को संकेत दिए गए हैं, और वास्तव में वास्तविक कोड शामिल नहीं है, इसलिए बैकअप के लिए यह बेकार है)

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

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

Answer 1

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

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

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

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

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

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 ... 

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

$ 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 --but मौजूदा, "स्थानीय" इतिहास दूर फेंक नहीं है के बराबर है।

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

Answer 2

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

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

Answer 3

मैं Damien's answer में जोड़ना चाहते हैं वह जहां सिफारिश की गई है:

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

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

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

• ।Git/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दोनों
  उन दूरदराज के खजाने की को "मास्टर" शाखा भेज दिए जाएंगे।

तुम भी contruction का उपयोग करके दो बार URL लिखना अपने आप को बचा सकते हैं:

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

Answer 4

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

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

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

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

Answer 5

नेस्टेड गिट रेपो रखने के लिए एक और तरीका है, लेकिन यह आपके बाद की समस्या का समाधान नहीं करता है। फिर भी, समाधान के लिए देख रहे अन्य लोगों के लिए मैं था:

शीर्ष स्तर के गिट रेपो में फ़ोल्डर को छिपाने के लिए .gitignore में नेस्टेड गिट रेपो युक्त फ़ोल्डर को छुपाएं। यह दो अलग (लेकिन घोंसला!) गिट repos होना आसान बनाता है।

Answer 6

क्या एक बार में अपने कई Git रेपोस के प्रबंधन के लिए mr उपयोग के बारे में: खजाने की एक सेट पर अन्य कार्रवाइयां

श्री (1) आदेश चेकआउट कर सकते हैं, अपडेट करने या प्रदर्शन के रूप में यदि वे एक संयुक्त थे respository। यह उपवर्तन, गिट, सीवी, मर्कुरियल, बीजेआर, डार्क्स, सीवीएस, वीसीएच, जीवाश्म और सत्यता भंडारों के किसी भी संयोजन का समर्थन करता है, और के लिए समर्थन अन्य संशोधन नियंत्रण प्रणाली को आसानी से जोड़ा जा सकता है। [...]

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

[...]

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