2012-06-22 17 views
7

हमारे फर्म में, हम SVN से Git में जाने के साथ प्रयोग कर रहे हैं। हम टीमों के लिए यह आसान बनाना चाहते हैं, जबकि sysadmins को बहुत अधिक बोझ नहीं करना चाहते हैं।गिट बैकअप: क्या मैं इसे दबाए जाने पर एक गिट नंगे भंडार की प्रतिलिपि बना सकता हूं?

हम एक (विंडोज़) नेटवर्क ड्राइव प्रत्येक टीम है पर एक नंगे भंडार बनाकर यह करने के लिए एक रास्ता मिल गया है, और धक्का/to/खींच कि से। प्रमाणीकरण फ़ाइल एक्सेस अनुमतियों के माध्यम से व्यवस्थित किया जाता है, इसलिए https और संपूर्ण ऑथ सामान सेट करने की आवश्यकता नहीं है। महान! (और हम वीपीएन के माध्यम से दूरस्थ रूप से ड्राइव तक पहुंच सकते हैं, इसलिए यह वास्तव में लगभग https या गिट + एसएसएच समाधान के रूप में अच्छा है)

बेहतर अभी तक, हम बैकअप भी मुफ्त में प्राप्त करेंगे, क्योंकि नेटवर्क शेयर पहले से ही समर्थित है अप। हालांकि, यह बैकअप अपेक्षाकृत अप्रत्याशित रूप से चलता है (बैकअप कई घंटे तक चलता है, इसलिए अगले कार्य दिवस पर जारी रह सकता है)।

इस प्रकार, यह संभव है कि ड्राइव का समर्थन किया जा रहा है जबकि एक डेवलपर रिपोजिटरी को दबा रहा है। एसवीएन के साथ, इससे समस्याएं पैदा हो सकती हैं, यही कारण है कि svn hotcopy मौजूद है।

एक ही जोखिम Git के साथ मौजूद है? क्या कोई इसे किसी नंगे भंडार की प्रतिलिपि बना सकता है जबकि कोई इसे दबा रहा हो? स्वाभाविक रूप से, यह सही है अगर पुश-किया-किया जा सकता है। यह भी ठीक है अगर बैकअप को पुनर्स्थापित करने के लिए कुछ काम किया जाना है, जिसे इसे धक्का दिया गया था (यानी आधे से किए गए पुश अवशेष डेटा को हटाकर)। लेकिन अगर पूरी नंगे भंडार टूट जाती है और अनुपयोगी होती है, तो यह एक समस्या है।

मैं कुछ प्रयोग किया है और समस्याओं को नहीं देख सकता था, लेकिन इसका मतलब यह नहीं है वहाँ किसी भी नहीं हो सकता है।

संपादित करें: मैंने इसे 'सही तरीके से करें' उत्तर स्वीकार किया, क्योंकि यही वह है जो मैं लंबे समय तक कर रहा हूं। अभी के लिए, हालांकि, हमारे लिए एक आसान समाधान git clone पूरे नंगे भंडार (उसी ड्राइव पर) से पहले स्वचालित बैकअप में आने से पहले एक आसान समाधान रहा है। स्वचालित बैकअप गलत तरीके से "असली" भंडार की प्रतिलिपि बना सकता है यदि उसके पास है उस बिंदु पर उपयोग में किया गया है, लेकिन हाल ही में क्लोन कॉपी के साथ इसे परेशानी नहीं होगी। हम जानते हैं कि बैकअप कब शुरू होता है, जब यह समाप्त होता है, तो यह हमारे लिए पर्याप्त नहीं है।

+2

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

+0

मुझे एहसास है कि 'गिट क्लोन' की कुछ भिन्नता शायद सबसे अच्छी होगी। बिंदु यह है कि, मानक फ़ाइल-कॉपी बैकअप तंत्र (पूरे ड्राइव के लिए, न केवल गिट रेपो) * पहले से ही * जगह पर है। मेरा सवाल यह है कि क्या वह पर्याप्त सुरक्षित है या नहीं। – skrebbel

उत्तर

2

पूरे गिट भंडार का बैक अप लेने के लिए अपनी बैकअप नीति को बदलने के लायक हो सकता है और इसके बजाय Git bundle बैकअप लें। Git's Little Bundle of Joy से:

बंडल आदेश सब कुछ है कि सामान्य रूप से होता है एक बाइनरी फ़ाइल है कि आप ईमेल या sneakernet कर सकते हैं चारों ओर में एक Git धक्का कमांड के साथ तार पर धकेल दिया पैकेज होगा, फिर एक और भंडार में अनबंडल।

इस दृष्टिकोण पर Backup of github repo और Backup a Local Git Repository में भी चर्चा की गई है।

एक स्थानीय रेपो के एक त्वरित परीक्षण निम्नलिखित सब कुछ एक आम तौर पर एक पूर्ण रेपो बैकअप में चाहते हैं कि एक एकल फ़ाइल बनाता है का पता चलता है:

$ git bundle create ../my.bundle --all 

बंडल फ़ाइल से एक क्लोन बनाना बस है:

$ git clone my.bundle my-repo 

git ls-remote my.bundle का उपयोग करके पता चलता है कि सभी टैग और शाखाएं बंडल में हैं।

हालांकि, बैकअप चीजें हैं जो शायद बंडल फ़ाइल में नहीं हैं (विन्यास, हुक, ग्राफ्ट, विकल्पों, आदि) के लिए, मैं बैकअप के लिए कुछ कदम आगे और बैकअप Git repository (लघु ले जाएगा objects, refs और logs निर्देशिकाएं) और बंडल फ़ाइल (objects और refs भंडार निर्देशिका की सामग्री बंडल में हैं और आवश्यक नहीं है)। बंडल में इन फ़ाइलों को शामिल नहीं किया जाता है; तो आपको केवल बंडल का बैकअप लेने की आवश्यकता है।

0

आप अन्य फ़ाइलों क्या बैकअप प्रक्रिया के दौरान संशोधित किया जा सकता है के साथ कैसे निपटते हैं?

आप पहले से ही इस स्थिति से निपटने, तो आप यहाँ एक ही दृष्टिकोण का उपयोग कर सकते हैं। अन्यथा आप कहीं भी टूटी हुई फाइलें प्राप्त कर सकते हैं, या तो गिट में, या svn में, या यहां तक ​​कि नंगे TXT में भी।

संबंधित मुद्दे