ধাক্কা দেওয়ার চেষ্টা করার সময় গিট ত্রুটি - প্রাক-গ্রহণের হুকটি অস্বীকার করে


206

যখন আমি চেষ্টা করেছি এবং আমি যে পরিবর্তনটি সম্পাদন করেছি তাতে চাপ দিই, আমি নিম্নলিখিত ত্রুটিটি পাই ...

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'

কি হচ্ছে?


8
প্রাক-প্রাপ্ত হুকন মাইকগিটে কী আছে?
রব মেয়োফ

আপনি কি বড় ফাইলগুলিকে গিথুবের দিকে ঠেলে দেওয়ার চেষ্টা করছেন না?
অ্যাডাম এফ

এফওয়াইআই: আজ আমার সমস্ত সহকর্মীরাই এই ত্রুটিমীমাটি পেয়েছে, শেষ পর্যন্ত আমরা আমাদের স্ট্যাশ সার্ভারটি পুনরায় চালু করার সিদ্ধান্ত নিয়েছি এবং এটি যাদুতে স্থির হয়ে গেছে। সমস্যাটি আসলে কী ছিল আমাদের কোনও ধারণা নেই।
T_D

উত্তর:


125

আপনার কাছে জিজ্ঞাসা করা উচিত যে কে রেপো রক্ষণাবেক্ষণ করে git@mycogit/cit_pplus.git

আপনার প্রতিশ্রুতিগুলি সেই রেপুর pre-receiveহুক দ্বারা প্রত্যাখ্যান করা হয়েছিল (এটি একটি ব্যবহারকারী-কনফিগারযোগ্য স্ক্রিপ্ট যা আসন্ন কমিটগুলি বিশ্লেষণ করতে এবং সিদ্ধান্ত নিতে পারে যে তারা রেপোতে গৃহীত হওয়ার পক্ষে যথেষ্ট উপযুক্ত কিনা)।

সেই ব্যক্তিকে হুক আপডেট করার জন্য জিজ্ঞাসা করাও ভাল ধারণা, সুতরাং এটি প্রত্যাখ্যানের কারণগুলি মুদ্রণ করবে।

রক্ষণাবেক্ষণকারী যদি আপনি নিজে হন তবে মনে হয় সার্ভার-সাইডে আপনার সেটআপ নিয়ে সমস্যা হয়েছে। দয়া করে আরও তথ্য ভাগ করুন।


7
আমার ক্ষেত্রে, বিটবকেটের প্রতিশ্রুতিবদ্ধ বার্তার সামগ্রীর একটি বৈধতা ছিল, এটি জিরার টিকিটের সাথে মুখোমুখি হয়েছিল যা সেই মুহুর্তে অফলাইনে ছিল।
ভেটর নীল আভেলিনো

1
সুতরাং এটি কখন অনলাইনে পরিণত হবে?
শরিফ

5
আমার ক্ষেত্রে এটি ব্যবহারকারীর নাম এবং বিটবকেটে ব্যবহারকারীর নামটি মিল ছিল না। আমি বিটবকেট ব্যবহারকারীর নাম আপডেট করার অনুমতিপ্রাপ্ত ছিলাম না, তাই আমার নিজের প্রতিশ্রুতিগুলি পুনরায় সেট করতে হবে এবং আপডেট হওয়া ব্যবহারকারীর নাম দিয়ে আবার তাদের প্রতিশ্রুতিবদ্ধ হয়েছিল। আপনি এই আদেশটি দিয়ে গিট ব্যবহারকারীর নাম আপডেট করতে পারেনgit config user.name 'UpdatedUserName'
এমএম

3
আমাদের ক্ষেত্রে বিটবাকেট এই শাখায় কাউকে চাপ দিতে দেয়নি।
রামন ফিনকেন

আমার ক্ষেত্রে আমাকে বিটবাকেটে রেপো সেটিংসগুলি খুঁজে পেতে এবং হুকস সেটিংসের অধীনে যাচাইকরণ প্রতিশ্রুতিবদ্ধ অক্ষম করতে হয়েছিল।
সিজনস

78

আমি বাজি ধরছি যে আপনি একটি দ্রুত-অগ্রসর না করা ধাক্কা চেষ্টা করছেন এবং হুক এটি আটকায়। যদি এটি git pull --rebaseহয় তবে সর্বাধিক নতুন কোডবেসে আপনার স্থানীয় পরিবর্তনগুলি পুনরায় চালু করার আগে চালিত করুন।


এটা সত্যিই দারুন. এখন আমি আবার ধাক্কা দিতে পারি এবং টানতে পারি, তবে এর আগে আমাকে যেমন স্ট্রিম সেট আপ করা দরকার git branch --set-upstream-to=origin/myBranch। আপনার উত্তরের জন্য +1।
অলোকটি

একটি নতুন সংগ্রহশালায় আমি একটি শাখা ঠেকিয়েছি (মাস্টার নয়), তারপরে এটি প্রত্যাখ্যান করে এবং চাপ দেওয়ার সময় ত্রুটি পেয়েছি। আমি ওয়েব-হুক পাইনি। আমি মৃত্যুদন্ড কার্যকর করলাম git pull --rebase, আবার পুনঃব্যবহার করতে হয়েছিল এবং শাখাটি পুশ করতে সক্ষম হয়েছি। অবশেষে আমি দেখতে পেলাম যে আমার শাখাটি সুরক্ষিত হয়ে গেছে।
কুলমাইন্ড

60

ফাইল আকার গুরুত্বপূর্ণ। একটি একক ফাইলের জন্য সীমা রয়েছে ~ 120MB। আমার ক্ষেত্রে, .gitignore ভিজ্যুয়াল স্টুডিও ব্যবহার করে ফাইলটি তালিকাভুক্ত ছিল, তবে ফাইলটি প্রতিশ্রুতিবদ্ধ ছিল। গিট ক্লিপ ব্যবহার করার সময়, আমরা ত্রুটি সম্পর্কে আরও বিশদ তথ্য পেতে পারি।

প্রাক-প্রাপ্ত হুক প্রত্যাখ্যান বড় ফাইলের ফলস্বরূপ ছিল। মূলত ধাক্কা বৈধকরণ।

এটি সমাধানের জন্য, আমি ব্যবহার করে শেষ প্রতিশ্রুতি সরিয়েছি:

git reset --soft HEAD~1

আমি তখন ফাইলটি কমিট থেকে বাদ দিয়েছি।

দ্রষ্টব্য: পূর্ববর্তী কমিটগুলির N নম্বরে ফিরে যেতে HEAD ~ N ব্যবহার করুন। (যেমন 3, 4) ফোল্ডারে পরিবর্তন বজায় রাখতে সর্বদা - সোফট সুইচটি ব্যবহার করুন

আশা করি এটা সাহায্য করবে.


এটির সাহায্যে আমার সমস্যাটি হ'ল অবাঞ্ছিত এসকিউএল ডাম্প ফাইল (ফাইলের আকারে 155 এমবি) চাপ দেওয়া হচ্ছে (দুর্ঘটনায়)।
মেহরদাদ দস্তগীর

1
ফাইলের আকার সীমা আপনার হোস্টিং সরবরাহকারীর উপর নির্ভর করে। গিটহাবের সেই আকারের চারপাশে একটি সীমা থাকে, অন্যদের জন্য এটির পরিবর্তিত হয় এবং স্ব-হোস্টেড গিট স্বাভাবিকভাবেই এর সীমাবদ্ধতা থাকে না।
1615903

1
আপনার যদি ইতিমধ্যে অস্বীকার করা ধাক্কার পরে বেশ কয়েকটি প্রতিশ্রুতি থাকে তবে আপনি কী করবেন? এটি আমার ক্ষেত্রে রেপোতে চাপ দেওয়ার আগে আমার পূর্ববর্তী কমিটগুলির একটিতে একটি অযাচিত বড় ফাইল (7২7 এমবি) রয়েছে
LeeCoder

আমার দুর্ঘটনাক্রমে একটি সিএসভি ফাইল আপলোড করা হয়েছিল। সুতরাং আমার ক্ষেত্রে, ত্রুটি তার কারণে হয়েছিল।
টোনোজি

আপনার যদি বেশ কয়েকটি কমিট করে থাকেন তবে সেই কমিটটিকে আবার সেট করতে সূচি বাড়ান। উদাহরণস্বরূপ, পূর্ববর্তী তিনটি কমিটিতে ফিরে যেতে হেড ~ 3 ব্যবহার করুন। ফোল্ডারে পরিবর্তনগুলি বজায় রাখতে সর্বদা - সাফ্ট সুইচটি ব্যবহার করুন।
ওজকারি

13

এটি হতে পারে কারণ কোনও শাখায় প্রতিশ্রুতিবদ্ধ হওয়ার জন্য আপনার কাছে অ্যাক্সেসের অধিকার ছিল না master। আপনি রক্ষণকারীকে আপনাকে কমিটগুলি ঠেকানোর অধিকার দিতে বলতে পারেন।


আমি মনে করি এটি সঠিক, তবে যা আকর্ষণীয় তা ভিএস মনে হচ্ছে মূল শাখাটির নাম রিমোটে নয় বরং মূল শাখার দিকে ঠেলে দেওয়ার চেষ্টা করছে। সুতরাং যদি মূল শাখাটি সুরক্ষিত থাকে তবে মনে হচ্ছে এটি ঘটতে পারে তবে ভিএস-এ এটি সংশোধন করার উপায় নেই এবং আপনাকে সেমিডি লাইনে স্যুইচ করতে হবে।
চিহ্নিত করুন

9

আমার ক্ষেত্রে আমি এই বার্তাটি পেয়েছি কারণ শাখাটি গিটল্যাবে 'সুরক্ষিত' হিসাবে চিহ্নিত হয়েছে।


1
দেখুন stackoverflow.com/a/28832644/2914140 বা GitLab প্রকল্পের> সেটিংস> সংগ্রহালয় তারপর Protected Branchesএটা খুঁজে বের করা।
কুলমাইন্ড

8

গিটল্যাব সার্ভারটিতে যখন কিছু পরিবর্তন চলছে তখন আমি এই বার্তাটি পেয়েছি। পরের দিন ঠেলাঠেলি ভাল কাজ। যাইহোক, অন্যরা যেমন নির্দেশ করেছে, নিশ্চিত হতে আপনার রক্ষণদাতার সাথে চেক করুন।


1
সবেমাত্র এই সমস্যাটি ছিল এবং আমার ধারণা গিটল্যাব পরিবর্তন করছে। এটি 10 ​​মিনিট সময় দিয়েছিল এবং এটি কাজ করে। আমি কিছুই পরিবর্তন করিনি।
woter324

ঠিক এই সমস্যাটিও ছিল। যে কেউ যদি এই ঘটনাটি
রেনান ফেরারি

5

দূরবর্তী সংগ্রহস্থলের অনুমোদিত ফাইলের আকারের চেয়ে বড় ফাইলের আকারের সাথে পরিবর্তনগুলি মার্জ করার চেষ্টা করার সময় আমার এই সমস্যাটি ছিল (আমার ক্ষেত্রে এটি গিটহাব ছিল)


2
আমার ক্ষেত্রেও ফাইলটি মুছে ফেলার পরেও গিটহাব এখনও অভিযোগ করেছে ... তবে এই উত্তরটি ট্র্যাকটি
কোডেনামডুচেস

5

আমি এই একই সমস্যার মুখোমুখি হয়েছি।
আমার পক্ষে কী সমাধান হয়েছিল তা হ'ল অন্য শাখায় স্যুইচ করা এবং তারপরে মূল শাখায় ফিরে যাওয়া।

আন্ডারলাইন কারণ কী তা নিশ্চিত নয় তবে এটি এটি স্থির করেছে।



3

বিটবকেট : সেটিংসে শাখার অনুমতিগুলির জন্য চেক করুন (এটি 'সমস্ত অস্বীকার করুন' তে থাকতে পারে)। যদি এটি কাজ না করে, কেবল আপনার শাখাটিকে একটি নতুন স্থানীয় শাখায় ক্লোন করুন , রিমোটগুলিতে পরিবর্তনগুলি চাপুন (একটি নতুন দূরবর্তী শাখা তৈরি হবে) এবং একটি PR তৈরি করুন।


2

যদি এটি কাউকে সহায়তা করে:

আমার চালানোর আগে অরক্ষিত (গিটল্যাবে) মাস্টার শাখাবিহীন একটি ফাঁকা রেপো ছিল git push -u origin --all

  • আমাকে দৌড়াতে হয়েছিল git push -u origin master ,
  • অস্থায়ীভাবে মাস্টার শাখা অরক্ষিত করুন
  • বাকীটি ধাক্কা ( --all& --tags)

2

আমি একই ত্রুটির মুখোমুখি হয়েছি, যাচাই করে আমার বিকাশকারী অ্যাক্সেস পেয়েছে এবং একটি নতুন শাখা প্রকাশ করতে পারিনি। উচ্চতর অ্যাক্সেসের অধিকার যুক্ত করা এই সমস্যার সমাধান করেছে G (গিটল্যাব)


2

আমি এই ত্রুটিটি গিটহাবের সংক্ষেপে পেয়েছি। আমি সাব-ডিরেক্টরিগুলিতে ফাইলগুলির সাথে একটি প্রতিশ্রুতি দেওয়ার চেষ্টা করছিলাম। দেখা গেছে যে সংক্ষেপে কেবলমাত্র রুট ডিরেক্টরিতে ফাইল থাকতে পারে।


এটাও পেয়েছি। দেখা যাচ্ছে যে রেপোতে ফাইলটি ছিল "snippets\\csharp.json"যা উইন্ডোজে শক্ত সময় দেয়।
কার্ল ওয়ালশ

2

সুরক্ষিত শাখা বিকল্পটি সরান বা বিকাশকারীদের বা প্রশাসকদের মতো অতিরিক্ত ভূমিকার অনুমতি দিন যাতে এই ত্রুটিটি অনুভব করা এই ব্যবহারকারীদের একত্রীকরণ এবং ধাক্কা দেওয়ার অনুমতি দেয়।


1

আমার ক্ষেত্রে, আমাদের প্রতিশ্রুতিবদ্ধ বার্তাগুলির জন্য হুক রয়েছে, আমাদের সার্ভার স্ক্রিপ্ট কমিটগুলি গ্রহণ করে যদি তাদের কাছে প্রতিশ্রুতি বার্তার জন্য বিশেষ ফর্ম্যাট থাকে "<JIRA ID><Message>"। সংশ্লিষ্ট জিরার টিকিট না থাকলে বা প্রতিশ্রুতি বার্তায় কিছু বিশেষ প্রতীক থাকলে এটি (হুক) প্রতিশ্রুতি অস্বীকার করে। আমি যখন এই প্রতিশ্রুতিবদ্ধ বার্তায় /, [,> ইত্যাদি] যুক্ত করি, তখন সেই কাজগুলি সূক্ষ্মভাবে সরানো হয় তখন আমি এই ত্রুটির মুখোমুখি হয়েছি।


এই উত্তরটি সাহায্যের সম্ভাবনা কম, কারণ মূল পোস্টারটি (এবং ভবিষ্যতে অন্য যে কোনও লোকের কাছে) একটি প্রাক-প্রাপ্ত হুক হিসাবে কনফিগার করা আলাদা স্ক্রিপ্ট থাকবে।
aronisstav

1

এটি আসলে ঘটবে যখন বিটবকেটের সার্ভার সাইডে ওয়াইএসিসি সক্ষম করা হবে। ওয়াইএসিসি জিরার ইস্যুর নামগুলি প্রতিশ্রুতি বার্তায় উল্লেখ করার জন্য সক্ষম করে। সুতরাং যখনই আপনি কমপক্ষে কোনও প্রতিশ্রুতিবদ্ধ করুন আপনার জিরার নম্বরটি প্রতিশ্রুতি বার্তায় রাখুন এবং তারপরে আপনি নিজের বার্তা যুক্ত করতে পারেন।


1

আমি গিটক্রেন ব্যবহার করছিলাম এবং আমরা একটি স্থানীয় শাখা তৈরি করেছি, তারপরে আমরা এতে দুটি প্রত্যন্ত শাখা একত্রিত করেছিলাম এবং তারপরে আমরা স্থানীয় শাখাটি উত্সের দিকে ঠেলে দেওয়ার চেষ্টা করেছি। এটি একই ত্রুটি বার্তার সাথে কাজ করে না।

সমাধান ছিল স্থানীয় শাখা তৈরি ও প্রথম ধাক্কা উৎপত্তি এবং তারপর একত্রীকরণ না।


1

ইস্যু: "পুশ ব্যর্থ রেফার্স / হেড / - প্রাক-প্রাপ্ত হুক অস্বীকার করা হয়েছে"

আমি আমার উত্স শাখায় আমার পরিবর্তনগুলি এবং কোনও নির্দিষ্ট প্রকল্পের সংগ্রহস্থলের মাস্টার শাখায় কিছু পরিবর্তন করতে না পারার সমস্যার মুখোমুখি হয়েছি কারণ সেই রেপোর আকার 2 জিবি-র সীমাবদ্ধতার চেয়ে বেশি ছিল। এটি ত্রুটি ছুড়েছিল। এর কারণ আমরা অজান্তে পরীক্ষার ডেটাটিকে অন্য পরীক্ষার শাখা থেকে বিটবাকেটে ঠেলে দিয়েছি।

পুশ ব্যর্থ রেফ / মাথা / - প্রাক-প্রাপ্ত হুক প্রত্যাখ্যান

তাই পরীক্ষার চেষ্টা করা হ'ল অন্যান্য প্রকল্পের রেপোগুলির সাথেও এটি একই এবং তাদের কোনও সমস্যা ছিল না।

ফিক্স:

আমার সহকর্মী লক্ষ্য করেছেন যে আমরা যখন স্থানীয়ভাবে প্রকল্পটি ক্লোন করেছি, তখন প্রকল্পটির আকার ছিল 110MB। তারপরে আমরা পূর্বে মার্জ করা এবং সক্রিয় শাখাগুলি পরিষ্কার করতে শুরু করি যা আর প্রয়োজন নেই। একবার যখন কয়েকটি শাখার জন্য পরিষ্কার করা হয় তখন আমরা বুঝতে পারি যে রেপোর আকার 2 জিবি থেকে 120 এমবিতে নেমে গেছে। তারপরে আমরা পরিবর্তনগুলি আমার শাখায় ঠেকানোর চেষ্টা করেছি এবং এটি কার্যকর হয়েছে।


1

আমার ক্ষেত্রে আমার কাছে একটি নতুন সংগ্রহশালা ছিল, একটি শাখা ঠেলাঠেলি করা হয়েছিল ('ইউসিএ-', ',' মাস্টার 'নয়), এটিকে পুনরায় সাজানো, জোর করে আবার চাপানো এবং ত্রুটিটি পেয়েছি। কোনও ওয়েব-হুক বিদ্যমান নেই। আমি @ থিফমাস্টারgit pull --rebase হিসাবে মৃত্যুদন্ড কার্যকর করেছি পরামর্শ দেওয়া, আবার রি-বেসের ফলে ছিল এবং শাখার ধাক্কা করতে সক্ষম হন। তবে এটি ছিল একটি অদ্ভুত এবং কঠিন উপায়।

তারপরে আমি দেখলাম গিট পুশ ত্রুটি প্রাক-গ্রহণের হুক কমেছে । আমি দেখতে পেয়েছি যে আমার শাখা সুরক্ষিত হয়ে গেছে । আমি সুরক্ষা অপসারণ করেছি এবং জোর করে আবার চাপ দিতে পারি।

এখানে চিত্র বর্ণনা লিখুন


0

একটি ডক্কু দৃষ্টান্তের দিকে এগিয়ে যাওয়ার চেষ্টা করার সময় আমি এটি পেয়েছি। আমার সার্ভারে ডিস্কটি পূর্ণ ছিল।

দৌড়াতে 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% /

0

আমার জন্য রিমোট গিট সার্ভারে অনুমোদন সমস্যা সমাধান করে। এখানে চিত্র বর্ণনা লিখুন


0

আমার ক্ষেত্রে, এটি কারণ আমি ঘটনাক্রমে আমার অনিয়ন্ত্রিত ধাক্কায় একটি বিশাল ফাইল যুক্ত করেছি এবং আমি যতই টানুন বা পুনরায় সেট করুন বা আরএম করেছি তার পরেও আমি এ থেকে মুক্তি পেতে পারি না।

আমার নোংরা সমাধান তবে কার্যক্ষম সমাধান হ'ল বর্তমান ডিরেক্টরিটির নতুন নামকরণ করা, ডিরেক্টরিটি স্থানীয়টিতে পুনরায় ক্লোন করা এবং স্বনির্ধারিত স্থানীয় ডিরেক্টরিতে ম্যানুয়ালি পরিবর্তনগুলি প্রতিফলিত করা ...

এটি ভাল শোনাচ্ছে না তবে কাজ করে ...


1
আমি একই সমস্যার মুখোমুখি হয়েছি এবং @ k গিট রিসেট - সোফট হেড ~ 1 @ ওজকারীর পরামর্শ অনুসারে সাহায্য করেছে using
jarrettyeo

0

আমার জন্য ত্রুটিটি হ'ল এই প্রকল্পটির কোনও শাখা তৈরি হয়নি, এবং আমার ভূমিকা বিকাশকারী ছিল, তাই আমি কোনও শাখা তৈরি করতে পারি না, অনুরোধ করছি তারা আমাকে প্রাসঙ্গিক অনুমতি এবং সমস্ত কিছু এখনই ক্রমে সরবরাহ করুন!


0

একটি ডিফল্ট শাখা (উদাঃ master) আপনার রিমোটের জন্য এখনও বিদ্যমান নেই। সুতরাং আপনাকে প্রথমে masterগিট রিমোট সার্ভারে শাখা তৈরি করতে হবে (যেমন একটি ডিফল্ট README.mdফাইল তৈরি করা ) তারপরে pushএই কমান্ডটি ব্যবহার করে আপনার বিদ্যমান সমস্ত স্থানীয় শাখায় চেষ্টা করুন :

git push -u origin --all

0

আমার জন্য বিটবাকেট স্বয়ংক্রিয়ভাবে তাদের নীতি পরিবর্তন না করা অবধি সবকিছু ঠিকঠাক ছিল (21 এপ্রিল, 2020)। এটি সম্প্রতি ওয়ার্কস্পেস নামে পরিচিত একটি নতুন বৈশিষ্ট্যের সাথে সারিবদ্ধ হওয়ার জন্য ঘটে তাই আমি সন্দেহ করি এর সাথে এর কিছু আছে something

কার্যকরী : আমি (প্রশাসক হিসাবে) ইউআই-র ব্যবহারকারীদের ইমেল ঠিকানা যুক্ত করার জন্য নির্দেশাবলী অনুসরণ করেছি (আপনি যে ইমেলটি ব্যবহার করছেন সেটি পাওয়া যাবে)git config --list

এখানে চিত্র বর্ণনা লিখুন


-7

একটি নোড.জেএস সংস্করণ নির্দিষ্ট করা যেমন সমস্যার সমাধান করতে পারে

{
  "name": "myapp",
  "description": "a really cool app",
  "version": "1.0.0",
  "engines": {
    "node": "10.3.0"
  }
}
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.