धक्का देने की कोशिश करते समय त्रुटि आई - हुक को पूर्व-प्राप्त करने से मना कर दिया गया

Question

जब मैं कोशिश करता हूं और अपने द्वारा किए गए बदलाव को आगे बढ़ाता हूं, तो मुझे निम्नलिखित त्रुटि मिलती है ...

git.exe push -v --progress  "origin" iteration1:iteration1

remote: *********************************************************************
To ssh://git@mycogit/cit_pplus.git
! [remote rejected] iteration1 -> iteration1 (pre-receive hook declined)
error: failed to push some refs to 'ssh://git@mycogit/cit_pplus.git'

क्या चल रहा है?

Comments

प्री-प्राप्त हुकॉन माइकोगिट में क्या है?

— लूटना

आप बड़ी फ़ाइलों को धक्का देने की कोशिश नहीं कर रहे होंगे?

— एडम एफ

FYI करें: आज मेरे सभी सहयोगी को यह गलतफहमी हो गई है, आखिरकार हमने अपने स्टैश सर्वर को फिर से शुरू करने का फैसला किया और यह जादुई रूप से तय हो गया। हमें कोई पता नहीं है कि वास्तव में मुद्दा क्या था।

— T_D

Answer 1

आपको पूछना चाहिए कि जो कोई भी रेपो को बनाए रखता है git@mycogit/cit_pplus.git।

आपके कमिट्स को उस रेपो के pre-receiveहुक द्वारा अस्वीकार कर दिया गया था (यह एक उपयोगकर्ता-कॉन्फ़िगर करने योग्य स्क्रिप्ट है जिसका उद्देश्य आने वाले कमानों का विश्लेषण करना है और यह तय करना है कि क्या वे रेपो में स्वीकार किए जाने के लिए पर्याप्त हैं)।

उस व्यक्ति को हुक अपडेट करने के लिए कहना भी एक अच्छा विचार है, इसलिए यह अस्वीकृति के कारणों को प्रिंट करेगा।

यदि अनुचर आप स्वयं हैं, तो ऐसा लगता है कि आपको सर्वर-साइड पर अपने सेटअप में कोई समस्या है। कृपया अधिक जानकारी साझा करें।

Comments

मेरे मामले में, BitBucket के पास JIRA टिकटों के साथ सामना करने वाले प्रतिबद्ध संदेश सामग्री का सत्यापन था, जो उस समय ऑफ़लाइन था।

— वीटोर नील एवेलिनो

तो जब यह ऑनलाइन तय हो गया?

— शेरे

मेरे मामले में यह उपयोगकर्ता नाम में एक बेमेल था जिसके साथ कमिट जनरेट किए गए थे और उपयोगकर्ता नाम BitBucket में। मुझे BitBucket उपयोगकर्ता नाम अपडेट करने के लिए अधिकृत नहीं किया गया था, इसलिए मुझे अपने कमिट्स को रीसेट करना पड़ा और उन्हें फिर से अपडेट किए गए उपयोगकर्ता नाम के साथ प्रतिबद्ध करना पड़ा। आप इस कमांड के साथ git यूजरनेम अपडेट कर सकते हैंgit config user.name 'UpdatedUserName'

— MM

हमारे मामले में बिटबकेट ने किसी को भी इस शाखा में धकेलने की अनुमति नहीं दी।

— रेमन फिनकिन

मेरे मामले में मुझे बिटकॉइन पर रेपो सेटिंग्स ढूंढनी थी और हुक सेटिंग्स के तहत सत्यापित कमिटर को अक्षम करना था।

— सिजन्स

Answer 2

मुझे यकीन है कि आप एक गैर-फास्ट-फॉरवर्ड पुश की कोशिश कर रहे हैं और हुक इसे ब्लॉक करता है। यदि ऐसा है, git pull --rebaseतो नवीनतम कोडबेस पर अपने स्थानीय परिवर्तनों को वापस करने के लिए धक्का देने से पहले चलाएं ।

Comments

यह कमाल का है। अब मैं फिर से धक्का दे सकता हूं और खींच सकता हूं, लेकिन इसके पहले मुझे ऊपर की तरफ स्थापित होने की जरूरत है git branch --set-upstream-to=origin/myBranch। आपके उत्तर के लिए +1।

— आलोकटी

एक नए भंडार में मैंने एक शाखा (मास्टर नहीं) को धक्का दिया, फिर इसे विद्रोह किया और धक्का के दौरान त्रुटि मिली। मुझे वेब-हुक नहीं मिले। मैंने निष्पादित किया git pull --rebase, फिर से विद्रोह करना पड़ा और शाखा को धक्का देने में सक्षम था। अंत में मैंने पाया कि मेरी शाखा संरक्षित हो गई।

— कूलमाइंड

Answer 3

फ़ाइल का आकार महत्वपूर्ण है। एकल फ़ाइल के लिए ~ 120MB की सीमा है। मेरे मामले में,। Visualign स्टूडियो का उपयोग करने वाले .ignignore में फ़ाइल सूचीबद्ध थी, लेकिन फ़ाइल अभी भी प्रतिबद्ध थी। Git cli का उपयोग करते समय, हम त्रुटि के बारे में अधिक विस्तार से जानकारी प्राप्त कर सकते हैं।

पूर्व प्राप्त हुक अस्वीकृत बड़ी फ़ाइल के परिणामस्वरूप था। मूल रूप से पुश को मान्य करना।

इसे हल करने के लिए, मैंने उपयोग करके अंतिम प्रतिबद्ध हटा दिया:

git reset --soft HEAD~1

मैंने फिर फ़ाइल को कमिट से बाहर कर दिया।

नोट: पिछले कमियों के N नंबर पर वापस जाने के लिए HEAD ~ N का उपयोग करें। (अर्थात 3, 4) फ़ोल्डर में परिवर्तन बनाए रखने के लिए हमेशा --soft स्विच का उपयोग करें

आशा करता हूँ की ये काम करेगा।

Comments

इसने मेरी समस्या के रूप में मदद की क्योंकि एक अवांछित SQL डंप फ़ाइल (फ़ाइल आकार में 155mb) को धक्का दिया जा रहा था (दुर्घटना से)।

— मेहरदाद दस्तगीर

फ़ाइल आकार सीमा आपके होस्टिंग प्रदाता पर निर्भर करती है। GitHub के पास उस आकार के चारों ओर एक सीमा है, दूसरों के लिए यह भिन्न होता है, और स्व-होस्टित git में स्वाभाविक रूप से ऐसी सीमाएँ नहीं होती हैं।

— १११५

यदि आप पहले से ही ठुकराए गए धक्का के बाद कई काम करते हैं तो आप क्या करते हैं? यह मेरा मामला है मेरे पास एक अवांछित बड़ी फ़ाइल (627MB) है, जो पिछले रेपो

— leeCoder

मेरे पास एक CSV फ़ाइल थी जिसे दुर्घटना से अपलोड किया गया था। तो मेरे मामले में, त्रुटि उसी के कारण थी।

— टनहोजी

यदि आपके पास कई कमिट्स हैं, तो उस कमिट को वापस करने के लिए इंडेक्स बढ़ाएँ। उदाहरण के लिए, तीन पिछले कमिट्स पर वापस जाने के लिए HEAD ~ 3 का उपयोग करें। फ़ोल्डर में परिवर्तन बनाए रखने के लिए हमेशा --soft स्विच का उपयोग करें।

— ozkary

Answer 4

ऐसा इसलिए हो सकता है क्योंकि किसी शाखा को प्रतिबद्ध करने के लिए आपके पास अधिकार नहीं है जैसे कि master। आप अनुरक्षक से आपको कमिट्स पुश करने का अधिकार देने के लिए कह सकते हैं।

Comments

मुझे लगता है कि यह सही है, लेकिन क्या दिलचस्प वीएस लगता है कि मूल शाखा को धक्का देने की कोशिश हो रही है, न कि वास्तविक शाखा का नाम रिमोट। तो अगर मूल शाखा को संरक्षित किया जाता है तो ऐसा प्रतीत होता है लेकिन वीएस में इसे ठीक करने के लिए वैसे भी प्रतीत नहीं होता है और आपको cmd लाइन पर स्विच करना होगा।

— मार्क

Answer 5

मेरे मामले में मुझे यह संदेश मिला क्योंकि शाखा को गिटलैब में 'संरक्षित' के रूप में चिह्नित किया गया था।

Comments

देखें stackoverflow.com/a/28832644/2914140 या GitLab परियोजना> सेटिंग> भंडार है, तो Protected Branchesयह लगता है।

— कूलमैन्ड

Answer 6

मुझे यह संदेश तब मिला जब GitLab सर्वर कुछ परिवर्तनों से गुजर रहा था। अगले दिन काम ने ठीक किया। वैसे भी, जैसा कि दूसरों ने बताया, सुनिश्चित करने के लिए अपने अनुचर के साथ जांच करें।

Comments

बस यह मुद्दा था और मुझे लगता है कि GitLab परिवर्तन कर रहे थे। यह 10 मिनट दिया और यह काम किया। मैंने कुछ भी नहीं बदला।

— woter324

बस यह मुद्दा भी था। किसी के लिए है कि अगर यह मामला है की जाँच करना चाहते हो सकता है: status.gitlab.com

— रेनन फेरारी

Answer 7

जब रिमोट रिपॉजिटरी ने अनुमति दी थी (मेरे मामले में यह गीताप्रेस था) की तुलना में फाइल साइज के साथ बदलाव को मर्ज करने की कोशिश करते समय मेरे पास यह मुद्दा था

Comments

मेरे मामले में फ़ाइल को हटाने के बाद भी GitHub ने अभी भी शिकायत की ... लेकिन इस जवाब ने चाल stackoverflow.com/questions/19573031/…

— CodenameDuchess

Answer 8

मैंने इसी मुद्दे का सामना किया।
मेरे लिए इसका हल क्या था दूसरी शाखा में जाना और फिर मूल में वापस जाना।

यह निश्चित नहीं है कि अंडरलाइन कारण क्या था, लेकिन इसने इसे तय किया

Comments

मैं नई शाखा को न तो धक्का नहीं दे सकता

— zabop

Answer 9

Bitbucket : सेटिंग्स में शाखा अनुमतियों की जाँच करें (यह 'सभी को अस्वीकार करें') हो सकता है। यदि वह काम नहीं करता है, तो बस अपनी शाखा को एक नई स्थानीय शाखा में क्लोन करें , परिवर्तनों को रिमोट पर धकेलें (एक नई दूरस्थ शाखा बनाई जाएगी), और एक पीआर बनाएं।

Answer 10

मामले में यह किसी की मदद करता है:

मेरे पास एक खाली रेपो था जिसमें दौड़ने से पहले असुरक्षित (गीतालाब में) मास्टर शाखा नहीं थी git push -u origin --all

• मुझे git push -u origin masterपहले दौड़ना था ,
• अस्थायी रूप से मास्टर शाखा को असुरक्षित करें
• बाकी को धक्का ( --all& --tags)

Answer 11

मुझे एक ही त्रुटि का सामना करना पड़ा, जाँचने पर कि मेरे पास एक डेवलपर पहुंच थी और एक नई शाखा प्रकाशित नहीं कर सका। उच्च पहुँच अधिकार जोड़ने से यह समस्या हल हो गई। (Gitlab)

Answer 12

मुझे यह त्रुटि GitHub gist के साथ मिली। मैं उप-निर्देशिका में फ़ाइलों के साथ एक कमिट पुश करने की कोशिश कर रहा था। टर्न आउट गिस्ट में केवल रूट डायरेक्टरी में फाइलें हो सकती हैं।

Comments

यह भी मिल गया। रेपो ने बताया कि फाइल में "snippets\\csharp.json"एक कठिन समय था।

— कार्ल वॉल्श

Answer 13

संरक्षित शाखा विकल्प निकालें या इन उपयोगकर्ताओं को मर्ज और पुश करने के लिए इन उपयोगकर्ताओं को अनुभव करने की अनुमति देने के लिए डेवलपर्स या प्रवेश जैसी अतिरिक्त भूमिकाएं दें।

Answer 14

मेरे मामले में, हमारे पास प्रतिबद्ध संदेशों के लिए हुक हैं, हमारी सर्वर स्क्रिप्ट स्वीकार करती है कि क्या उनके पास प्रतिबद्ध संदेश के लिए विशेष प्रारूप है "<JIRA ID><Message>"। यह (हुक) यह निर्धारित करता है कि संबंधित जीरा टिकट मौजूद नहीं है या प्रतिबद्ध संदेश में कुछ विशेष प्रतीक हैं। मैं इस त्रुटि का सामना करता हूं जब मैं एक प्रतिबद्ध संदेश में /, [,> आदि जोड़ता हूं, उन कार्यों को ठीक करता है।

Comments

यह उत्तर मदद करने की संभावना नहीं है, क्योंकि मूल पोस्टर (और भविष्य में किसी और का दौरा करने वाले) के पास पूर्व-प्राप्त हुक के रूप में कॉन्फ़िगर की गई एक अलग स्क्रिप्ट होगी।

— एरोनिस्टावट

Answer 15

यह वास्तव में तब होता है जब YACC को BitBucket में सर्वर साइड में सक्षम किया जाता है। YACC JIRA मुद्दों के लिए प्रतिबद्ध संदेश में उल्लिखित नामों के लिए सक्षम है। इसलिए जब भी आप कम से कम कुछ करते हैं तो अपना JIRA नंबर कमिट मैसेज में रखें और फिर इसके अलावा आप अपना मैसेज भी जोड़ सकते हैं।

Answer 16

मैं GitKraken का उपयोग कर रहा था और हमने एक स्थानीय शाखा बनाई, फिर हमने इसमें दो दूरस्थ शाखाओं को मिला दिया और फिर हमने स्थानीय शाखा को मूल में धकेलने का प्रयास किया। यह एक ही त्रुटि संदेश के साथ काम नहीं किया।

समाधान के लिए गया था स्थानीय शाखा बना सकते हैं और पहले धक्का मूल करने के लिए और फिर मर्ज करते हैं।

Answer 17

समस्या: "PUSH विफल refs / head / - पूर्व-प्राप्त हुक अस्वीकृत"

मैंने अपनी मूल शाखा में अपने परिवर्तनों को धकेलने में असमर्थ होने का सामना किया है और किसी विशेष परियोजना भंडार की मास्टर शाखा को कुछ भी नहीं दिया है क्योंकि उस रेपो का आकार 2GB की कठिन सीमा से अधिक था। यह त्रुटि फेंक रहा था। ऐसा इसलिए है क्योंकि हमने परीक्षण डेटा को अनजाने में अन्य परीक्षण शाखाओं से बिटबकैट पर धकेल दिया था।

PUSH विफल रिफ / सिर / - पूर्व-प्राप्त हुक में गिरावट आई

तो जाँच की कोशिश की है कि अन्य परियोजना रेपो के साथ ही है और वे किसी भी मुद्दे नहीं थे।

ठीक कर:

मेरे सहकर्मी ने देखा कि जब हमने परियोजना को स्थानीय स्तर पर वापस किया, तो परियोजना का आकार 110 एमबी था। तो फिर हमने उन शाखाओं की सफाई शुरू कर दी जिन्हें हमने पहले और सक्रिय शाखाओं में मिला दिया था जिनकी अब और आवश्यकता नहीं है। एक बार कि सफाई दो शाखाओं के लिए किया जाता है, हमें एहसास हुआ कि रेपो का आकार 2GB से 120MB तक काफी नीचे चला गया है। फिर हमने अपनी शाखा में परिवर्तनों को आगे बढ़ाने का प्रयास किया और इसने काम किया।

Answer 18

मेरे मामले में मेरे पास एक नया भंडार था, एक शाखा को धक्का दिया ('यूसीए -46', 'मास्टर' नहीं), इसे विद्रोह किया, फिर से जबरन धक्का दिया और त्रुटि मिली। कोई वेब-हुक मौजूद नहीं था। मैंने @ThiefMaster केgit pull --rebase रूप में निष्पादित किया सलाह दी है, फिर rebase करने के लिए था और शाखा पुश करने के लिए कर रहा था। लेकिन वह एक अजीब और मुश्किल तरीका था।

फिर मैंने देखा Git पुश एरर प्री-रिसीव हुक में गिरावट आई । मैंने पाया कि मेरी शाखा संरक्षित हो गई । मैंने सुरक्षा हटा दी और फिर से जबरन धक्का दे सकता था।

Answer 19

मुझे यह तब मिला जब एक डॉक्यू उदाहरण पर धकेलने की कोशिश की गई। मेरे सर्वर पर डिस्क पूरी भरी हुई थी।

दौड़ा: du -f

और परिणाम था:

Filesystem      Size  Used Avail Use% Mounted on
udev            476M     0  476M   0% /dev
tmpfs           100M  4.4M   95M   5% /run
/dev/xvda1      7.8G  7.4G  8.9M 100% /

Answer 20

मेरे लिए दूरस्थ git सर्वर पर प्राधिकरण समस्या का समाधान करता है।

Answer 21

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

मेरा गंदा समाधान लेकिन व्यावहारिक समाधान वर्तमान निर्देशिका का नाम बदलने के लिए है, निर्देशिका को फिर से स्थानीय करने के लिए और फिर से प्रकाशित स्थानीय निर्देशिका में परिवर्तन को प्रतिबिंबित करने के लिए ...

यह अच्छा नहीं लगता है लेकिन काम करता है ...

Comments

मैं एक ही मुद्दे का सामना करना पड़ा, और $ git रीसेट का उपयोग कर रहा था-soft HEAD ~ 1 जैसा कि @ozkary ने मदद करने का सुझाव दिया।

— जरेटीओ

Answer 22

मेरे लिए त्रुटि यह थी कि इस परियोजना की कोई शाखाएँ नहीं बनी थीं, और मेरी भूमिका डेवलपर की थी, इसलिए मैं कोई भी शाखा नहीं बना सका, अनुरोध है कि वे मुझे अभी और क्रम में हर चीज की अनुमति दें!

Answer 23

एक डिफ़ॉल्ट शाखा (जैसे master) अभी आपके रिमोट के लिए मौजूद नहीं है। इसलिए आपको सबसे पहले mastergit रिमोट सर्वर में ब्रांच बनाने की जरूरत है (जैसे एक डिफॉल्ट README.mdफाइल बनाना) फिर pushइस का उपयोग करके अपनी सभी मौजूदा लोकल ब्रांचों में कोशिश करें :

git push -u origin --all

Answer 24

मेरे लिए तब तक सब कुछ ठीक चल रहा था जब तक कि आज (21 अप्रैल, 2020) बिटकॉइन ने स्वचालित रूप से अपनी नीति नहीं बदल दी। यह एक नई सुविधा के साथ संरेखित करने के लिए होता है जिसे हाल ही में आज वर्कस्पेस कहा जाता है , इसलिए मुझे संदेह है कि इसके साथ कुछ करना है।

समाधान : मैं (एक व्यवस्थापक के रूप में) यूआई में उपयोगकर्ताओं को ईमेल पता जोड़ने के निर्देशों का पालन करता हूं (आपके द्वारा उपयोग किया जा रहा ईमेल पाया जा सकता हैgit config --list

Answer 25

एक नोड .js संस्करण निर्दिष्ट करने से समस्या हल हो सकती है

{
  "name": "myapp",
  "description": "a really cool app",
  "version": "1.0.0",
  "engines": {
    "node": "10.3.0"
  }
}