2011-12-29 10 views
9

के प्रारंभिक धक्का करने का वैकल्पिक तरीका मुझे विकास और उत्पादन में काफी हद तक रेल 3.1 एप मिला है जिसे मैंने केवल हेरोोकू के लिए एक स्टेजिंग वातावरण स्थापित किया है। चूंकि मेरा गिट रेपो काफी बड़ा है, इसलिए जब भी मैं धक्का देने की कोशिश करता हूं, मुझे लगभग 33% समय-समय पर त्रुटियां मिल रही हैं।एक बड़े रेपो

क्या इस प्रारंभिक विशाल धक्का के लिए git push staging master करने का कोई विकल्प है?

त्रुटि संदेश

EmBP-2:Appname Emma$ git push staging master 
Counting objects: 17421, done. 
Delta compression using up to 4 threads. 
Compressing objects: 100% (6363/6363), done. 
Connection to 10.10.18.33 closed by remote host.46 KiB/s  
error: pack-objects died of signal 13 
error: failed to push some refs to '[email protected]:appname-staging.git' 

/////////////////// समाधान/संपादित है, कई महीने बाद ...

नहीं है यदि आप पहले से ही एक पर्यावरण स्थापित कर चुके हैं जिस पर आपने कोड को धक्का दिया है, तो उसे हल करने के लिए एक स्नीकी तरीका, आजकल, हेरोकू (प्रयोगात्मक) पाइपलाइन सुविधा का उपयोग करके। हेरोकू से docs:

"उदाहरण के लिए, आप कोड को स्टेजिंग करने के लिए पुश कर सकते हैं, इसे एक स्लग में बनाया गया है और बाद में स्टेजिंग स्लग को उत्पादन में बढ़ावा दिया जा सकता है।"

हरोकू के लिए एक ऐप से दूसरे ऐप को मौजूदा स्लग को धक्का देने के लिए लगभग 5 सेकंड लेता है!

+0

अरे, आप एक जवाब के रूप में नए पाया समाधान जोड़ सकता है? मैं अभी तक लागू नहीं कर सकता। धन्यवाद! – Chango

+0

आप यहां यह कैसे करना है इस पर सरल दस्तावेज़ीकरण पा सकते हैं: https://devcenter.heroku.com/articles/labs-pipelines - यह मेरे लिए काम करता है जहां अन्य सभी उत्तरों – jfdimark

उत्तर

5

विकल्प आपके विशाल प्रतिबद्धता को कई छोटे लोगों में विभाजित करना है। ऐसा करने से पहले टैग या शाखा। प्रत्येक में कई फाइलें होंगी जो उचित धक्का बनाती हैं। टिप को इंगित करने के लिए एक अस्थायी शाखा बनाएं। अब उन छोटी प्रतिबद्धताओं में से पहले मास्टर को रीसेट करें। धक्का दें। अगले प्रतिबद्धता के लिए मास्टर सेट करें। धक्का दें। इसे पूरा होने तक दोहराएं।

अब मूल रूप से मास्टर को पुनर्स्थापित करें। आप पहले से ही वस्तुओं को स्थानांतरित कर दिया है। इस बड़ी प्रतिबद्धता को धक्का देना उन सभी वस्तुओं को दोबारा नहीं भेजना चाहिए जो पहले से ही रिमोट पर मौजूद हैं।

+1

यह बेहद उबाऊ लगता है। ता, यद्यपि। – snowangel

+0

yup। बहुत भाग्यशाली लेकिन आपने एक विकल्प के लिए कहा;) –

+1

मुझे यह त्रुटि 'git: // 'रिमोट रेपो के साथ मिली थी। मैं 'गिट + एसएसएच: //' में बदल गया और यह ठीक काम किया। वाईएमएमवी ... –

0

नहीं, हेरोकू पर सामग्री प्राप्त करने का एकमात्र तरीका एक गिट पुश के माध्यम से है।

उत्सुकता से आपका प्रोजेक्ट फ़ोल्डर कितना बड़ा है?

+0

स्लग आकार जब मैं तैनात करता हूं मेरा उत्पादन env 72 एमबी है। मेरी स्थानीय मशीन पर, यह 560 एमबी है लेकिन इसमें स्क्लाइट 3 डीबी और गिटिग्नोर और स्लगिनगोर में अन्य सामानों का एक गुच्छा शामिल है। प्रतिक्रिया के लिए धन्यवाद - कम से कम मुझे पता है कि कोई आसान विकल्प नहीं है। – snowangel

+0

क्या आपके पास वहां बहुत सारी स्थिर संपत्तियां हैं? शायद उन्हें एस 3 पर होस्ट करना बेहतर होगा? –

+0

नहीं, सभी स्थैतिक संपत्तियां पहले ही एस 3 पर हैं। मैंने जितना संभव हो उतना गिटिग्न किया है ... – snowangel

8

मैं वीडियो के साथ कुछ परिवर्तन पुश करने के लिए कोशिश कर रहा था और मिल गया:

fatal: The remote end hung up unexpectedly 
error: pack-objects died of signal 13 
error: failed to push some refs to '[email protected]/XXX.git' 

मेरे लिए समाधान था:

git repack 
git push 

आशा इस

3

प्रति एडम जवाब में मदद मिलेगी, आप कर सकते हैं अपने बड़े धक्का को तोड़ें जिसमें कई काम करता है (और उनके ब्लब्स) कई छोटे धक्का देते हैं जिनमें प्रत्येक को आपकी शाखा के इतिहास के लिए आवश्यक प्रतिबद्धता का सबसेट होता है।

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

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

एक नया रिमोट शाखा master को पुश करने के लिए, चलाने

git log --reverse --oneline | sed -n '0~100p' | awk '{print "git push staging "$1":refs/heads/master"}' | while read i; do eval $i; done 

प्रत्येक धक्का अगले 100 करता आ जाएगी और केवल नई वस्तुओं (या उनके डेल्टा) करता है कि बैच में पाया पुश करने के लिए की जरूरत है। अंत में, आप वर्तमान HEAD प्रतिबद्ध के शेष के पुश करने के लिए धक्का, और अंतिम दूरस्थ शाखा बनाने की जरूरत:

git push staging HEAD:master