क्या गिट में "! [rejected] master -> master (fetch first)'" को हल करने का तरीका समझाने का एक अच्छा तरीका है?! [अस्वीकार] मास्टर -> मास्टर (पहले लाने)
जब मैं इस आदेश का उपयोग करता हूं $ git push origin master यह एक त्रुटि संदेश प्रदर्शित करता है।
! [rejected] master -> master (fetch first)
error: failed to push some refs to '[email protected]:zapnaa/abcappp.git'
उत्तर है, गिट आपको पहले लाने के लिए कह रहा है।
शायद किसी और ने पहले से ही मास्टर को धक्का दिया है, और आपकी प्रतिबद्धता पीछे है। इसलिए आपको लाने, परिवर्तन को मर्ज करना होगा, और फिर आप फिर से धक्का दे पाएंगे।
यदि आप --force विकल्प का उपयोग करके इसे मजबूर नहीं करते हैं (या इससे भी बदतर), तो आप प्रतिबद्ध इतिहास को गड़बड़ कर सकते हैं।
संपादित करें: मुझे अंतिम बिंदु के बारे में अधिक जानकारी मिलती है, क्योंकि यहां एक लड़के ने --force विकल्प का उपयोग करने की बहुत खराब सलाह दी है।
चूंकि गिट एक डीवीसीएस है, आदर्श रूप से कई अन्य डेवलपर उसी प्रोजेक्ट पर काम कर रहे हैं, उसी भंडार (या इसका कांटा) का उपयोग करते हुए। यदि आप अपने परिवर्तन के साथ मजबूती से ओवरराइट करते हैं, तो आपकी रिपोजिटरी अन्य लोगों के मेल नहीं खाएगी, क्योंकि "आप इतिहास को फिर से लिखते हैं"। आप अन्य लोगों को नाखुश बना देंगे और भंडार भुगतना होगा। शायद दुनिया में एक बिल्ली का बच्चा भी रोएगा।
टी एल; डॉ
--force विकल्प का उपयोग करें।आपने पूर्व के लिए पूछा, हालांकि। 1 के लिए जाएं) हमेशा, भले ही आप हमेशा अपने आप से गिट का उपयोग करेंगे, क्योंकि यह एक अच्छा अभ्यास है।
स्थानीय फ़ाइलों में महत्वपूर्ण परिवर्तनों को हटा सकते हैं प्राप्त करने में कठिनाई नहीं? –
यह लिखा गया है कि – dhein
@Dhein जैसा मैंने लिखा था, fetch को एक विलय के बाद किया जाना चाहिए - बिंदु यह है कि आपको स्थानीय पेड़ को दूरस्थ पेड़ (इसलिए विलय के साथ) "संरेखित करना होगा - लेकिन धन्यवाद, मैंने इसे टीएल में लिखा था; डीआर भी – linuxbandit
इस Git आदेश
git push origin master --force
या बल -f
git push origin master -f
धन्यवाद @ उपयोगकर्ता 1865618, गिट पुश मूल मास्टर - फोर्स। इस आदेश ने मेरा समय –
बचाया है, यह पढ़ने के लिए मजाकिया है, अन्य उत्तरों को पढ़ने के बाद कह रहा है: 'ऐसा मत करो, जब तक आप नहीं जानते कि आप क्या कर रहे हैं'। :-) – Zeth
यह गिट पुश प्रतिबंध ओवरराइड करता है। टीमवर्क के लिए अनुशंसित नहीं है।गिट पुश दस्तावेज से: _ अगर आप किसी अन्य व्यक्ति को अपने मूल इतिहास के शीर्ष पर बनाया गया है, तो रिमोट पर, रिमोट पर शाखा की नोक उसकी प्रतिबद्धता के साथ आगे बढ़ सकती है, और अंधेरे से जोर देकर --force will_ ** उसका काम खो देगा **। – Casey
आप git pull का उपयोग करना चाहिए की कमी का प्रयास करें, यही आदेश एक git fetch करते हैं और अगले git merge है।
यदि आप git push origin master --force कमांड का उपयोग करते हैं, तो आपको भविष्य में समस्याएं हो सकती हैं।
क्या यह सही है कि आपको केवल फोर्स का उपयोग करना चाहिए यदि आप प्रोजेक्ट पर एकमात्र हैं और आप अपना पहला धक्का करने की कोशिश कर निराश हो रहे हैं? – Chrips
पुल हमेशा सही दृष्टिकोण है लेकिन एक अपवाद तब हो सकता है जब आप किसी भी गिटब फ़ाइल को गिटूब रिपोजिटरी में कनवर्ट करने का प्रयास नहीं कर रहे हों। वहां आपको पहली प्रतिबद्धता को मजबूर करना होगा।
git init
git add README.md
git add .
git commit -m "first commit"
git remote add origin https://github.com/userName/repoName.git
git push --force origin master
मेरे लिए काम करता है, मैंने फिर से एक नई परियोजना शुरू की (एक ही रेपो) और मैं इसे बदलना चाहता था। – ucotta
कोशिश:
git fetch origin master
git merge origin master
के बाद इस कोड को मैं अन्य त्रुटि प्राप्त लिखा: (गैर तेजी से आगे)
मैं इस कोड लिखने:
git fetch origin master:tmp
git rebase tmp
git push origin HEAD:master
git branch -D tmp
और मेरी समस्या का समाधान
मेरे लिए वही है। यह मेरी समस्या हल हो गई। कुछ चेतावनियां हैं। मैं एक उप भंडार के साथ गड़बड़ कर दिया, लेकिन इसे हल किया: http://stackoverflow.com/questions/19584255/what-does-a-grey-icon-in-remote-github-mean –
धन्यवाद यह मेरे लिए काम कर रहा है – core114
यह ' संभावना है कि कोई और (उदा। आपके सहयोगी) ने origin/master पर काम किया है जो आपके स्थानीय master शाखा में नहीं हैं, और आप अपनी स्थानीय शाखा से सर्वर पर कुछ काम करने की कोशिश कर रहे हैं। 99% मामलों में, मानते हुए कि आप origin से अपना काम मिटाना नहीं चाहते हैं, आपके पास दो विकल्प हैं:
2) अपने परिवर्तनों को अपनी स्थानीय शाखा में मर्ज करें, और उसके बाद मर्ज किए गए परिणाम को दबाएं। git checkout master git pull # resolve conflicts here git push
(ध्यान दें कि git pull अनिवार्य रूप से सिर्फ एक git fetch और इस मामले में एक git merge है।)
1) अपने स्थानीय शाखा rebase, इतना है कि यह लगता है कि आपके सहयोगी उनके प्रतिबद्ध पहले बनाया है, और उसके बाद आपके द्वारा किए गए अपने करता है। यह प्रतिबद्धता इतिहास को अच्छा और रैखिक रखता है - और "विलय प्रतिबद्धता" से बचाता है। हालांकि, अगर आपके सहयोगी के परिवर्तनों के साथ संघर्ष है, तो आपको सबसे खराब मामले में अपने प्रत्येक काम (केवल एक बार के बजाय) के लिए उन संघर्षों को हल करना पड़ सकता है। अनिवार्य रूप से यह हर किसी के लिए अच्छा है लेकिन आपके लिए अधिक प्रयास है। git pull --rebase # resolve conflicts here git push
(ध्यान दें कि git pull --rebase अनिवार्य रूप से एक git fetch और एक git rebase origin/master है।)
कभी कभी यह तब होता है जब आप डुप्लिकेट फ़ाइलें आम तौर पर एक तरह से रीडमी। , पहले क्लोन अपने रेपो की ताज़ा प्रति --mirror ध्वज का उपयोग:
आप निम्न आदेश का उपयोग कर सकते हैं
$ git clone --mirror git://example.com/some-big-repo.git
फिर उसके अनुसार कोड का पालन करें:
Adding an existing project to GitHub using the command line
यहां तक कि यदि यह काम नहीं करता है, तो आप बस कोड कर सकते हैं:
$ git push origin master --force
या
$ git push origin master -f
एक ही समस्या: डी – core114