গিট অ-ফাস্ট-ফরোয়ার্ড প্রত্যাখ্যাত

Question

আমার মনে হচ্ছে এই প্রশ্নটি অনেকবার জিজ্ঞাসা করা হয়েছে, তবে সমাধানটি সাধারণত "আমি ডিরেক্টরিটি মুছে ফেলেছি এবং একটি নতুন চেকআউট দিয়ে আমার কাজটি আবার করেছি।" আমি একটি প্রতিশ্রুতিবদ্ধ এবং ধাক্কা দিয়েছি কিন্তু বুঝতে পারি যে আমি প্রতিশ্রুতি বার্তায় ভুল টিকিট নম্বর উল্লেখ করেছি। তাই আমি দ্রুত সমাধানের জন্য এসওয়ের দিকে চেয়েছিলাম এবং টার্মিনালে নিম্নলিখিতটি লিখে শেষ করেছি:

$ git reset --soft HEAD^
$ git commit -m "... correct message ..."

একমাত্র সমস্যা হ'ল আমি নিম্নলিখিত ত্রুটি বার্তাটি পাচ্ছি:

To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again.  See the 'Note about
fast-forwards' section of 'git push --help' for details.

আমি গিট-ফ্লো মডেলটি ব্যবহার করছি এবং বিকাশ শাখায় কাজ করছি। গিটকে আবার খুশি করতে আমি কীভাবে জিনিসগুলিকে আবার মার্জ করতে পারি?

Comments

গিতে "ফাস্ট-ফরোয়ার্ড" কীসের

Answer 1

বাহিনী git push:

git push origin +develop

Comments

এটি একটি সমাধান, তবে ব্রায়ান ক্যাম্পবেলের মন্তব্যটি পড়ুন যাতে আপনি এটি ব্যবহার করার আগে আপনি কী করছেন তা বুঝতে পারবেন।

— থেলেম

গিট পুশ অরিজিন + মাস্টার

— অনিকেত ঠাকুর

এছাড়াও দেখতে নোট receive.denyNonFastForwardsমধ্যে ব্রায়ান ক্যাম্পবেল এর উত্তর : +বা --forceপর্যাপ্ত জোরালো নাও হতে পারে, কিভাবে তারা-কেবা তারা-আছে কনফিগার উপর নির্ভর করে তাদের গীত সংগ্রহস্থল।

— টেরেক

Answer 2

আপনি ধাক্কা যদি একটি সার্ভারে কমিট, এবং তারপর পুনর্লিখন স্থানীয় ভাবে (সঙ্গে কমিট git reset, git rebase, git filter-branch, বা অন্য কোন ইতিহাস ম্যানিপুলেশন), এবং তারপর ধাক্কা যে পুনর্লিখিত ফিরে সার্ভারে আপ কমিট, আপনি অন্য কেউ টানা ছিল স্ক্রু আপ হবে। এখানে একটি উদাহরণ; বলুন যে আপনি A প্রতিশ্রুতিবদ্ধ করেছেন এবং এটি সার্ভারে ঠেলে দিয়েছেন।

- * - * - এ <- মাস্টার

- * - * - এ <- উত্স / মাস্টার

আপনারা যেভাবে উল্লিখিত, পুনরায় সেট করা এবং পুনরায় প্রতিশ্রুতিবদ্ধ সেভাবে এখন আপনি এটিকে পুনরায় লেখার সিদ্ধান্ত নিন। নোট করুন যে এটি একটি ঝুঁকিপূর্ণ প্রতিশ্রুতি ছেড়ে দেয়, এ, যা অবশেষে এটি আবশ্যক না হওয়ায় আবর্জনা সংগ্রহ করা হবে।

- * - * - এ
    \
     এ '<- মাস্টার

- * - * - এ <- উত্স / মাস্টার

যদি অন্য কেউ, ফ্রেডকে বলুন masterযে আপনি এই কাজটি করার সময় সার্ভার থেকে সরিয়ে ফেলেন , তাদের A এর একটি রেফারেন্স থাকবে, যা থেকে তারা কাজ শুরু করতে পারে:

- * - * - এ '<- মাস্টার

- * - * - এ <- উত্স / মাস্টার

- * - * - এবি <- ফ্রেড / মাস্টার

এখন আপনি যদি আপনার 'আ' কে উত্স / মাস্টারে চাপ দিতে সক্ষম হন যা একটি অ-ফাস্ট-ফরোয়ার্ড তৈরি করে, এটির ইতিহাসে এটির কোনও দরকার নেই। সুতরাং ফ্রেড যদি আবার টানতে চেষ্টা করে, তবে হঠাৎ তাকে একীভূত করতে হবে এবং এ কমিটিকে নতুন করে পরিচয় করিয়ে দেবেন:

- * - * - এ '<- মাস্টার

- * - * - এ <- উত্স / মাস্টার

- * - * - এবি \ 
    \ * <- ফ্রেড / মাস্টার
     এ '- /

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

সুতরাং, অন্যান্য লোকেদের কাছ থেকে নেওয়া কোনও রেপোতে ইতিহাস পরিবর্তন করা সাধারণত ভাল ধারণা নয়। তবে, আপনি যদি জানতে পারেন যে এই রেপো থেকে অন্য কেউ টানছেন না (উদাহরণস্বরূপ, এটি আপনার নিজস্ব ব্যক্তিগত রেপো, বা আপনি কেবল অন্য প্রকল্পে কাজ করছেন যার সাথে আপনি সহজেই সমন্বয় করতে পারেন) তবে আপনি জোর করেই চালিয়ে আপডেট করুন:

git push -f

বা

git push origin +master

এগুলি উভয়ই দ্রুত-অগ্রসর না হওয়া ধাক্কা দেওয়ার জন্য চেক উপেক্ষা করবে এবং সার্ভারে থাকা আপনার নতুন এ'র সংশোধনকে আপডেট করবে, এ রিভিশনটি ত্যাগ করবে যাতে শেষ পর্যন্ত তা আবর্জনা সংগ্রহ করা যায়।

এটি সম্ভব যে ফোর্স পুশগুলি receive.denyNonFastForwardsকনফিগার বিকল্পের সাহায্যে সম্পূর্ণ অক্ষম থাকে are ভাগ করা সংগ্রহস্থলগুলিতে এই বিকল্পটি ডিফল্টরূপে সক্ষম হয়। সেক্ষেত্রে, যদি আপনি সত্যই সত্যই একটি জোর চাপতে চান তবে সর্বোত্তম বিকল্পটি হ'ল শাখাটি মুছে ফেলা এবং এটি দিয়ে পুনরায় তৈরি করা git push origin :master; git push origin master:master। যাইহোক, denyNonFastForwardsবিকল্পটি একটি কারণে সক্ষম করা হয়েছে, যা উপরে বর্ণিত হয়েছে; একটি ভাগ করা সংগ্রহস্থলের উপর, এর অর্থ হ'ল এখন যারাই এটি ব্যবহার করেন তাদের অবশ্যই এটি নতুন ইতিহাসের দিকে প্রত্যাবর্তন করা উচিত তা নিশ্চিত হওয়া উচিত।

একটি ভাগ করা ভান্ডারগুলিতে, কেবলমাত্র নতুন কমিটগুলি উপরে চাপানো ভাল যা আপনার যে কোনও সমস্যাই স্থির করে; আপনি git revertকমিটগুলি তৈরি করতে ব্যবহার করতে পারেন যা পূর্ববর্তী কমিটগুলির পরিবর্তনগুলি পূর্বাবস্থায় ফিরিয়ে আনবে।

Comments

দুর্দান্ত শিক্ষা, এবং আপনি শেষ অবধি কমান্ডটি পেয়েছিলেন, তবে আমার শাখাটিকে বিকাশ (গিট-প্রবাহের উপর ভিত্তি করে) বলা হয়েছিল, এবং অন্য লোকটি +developতাঁর আদেশে রেখেছিল - তাই চেকটি তার কাছে যায় goes আপনি যেভাবেই হোক জ্যোতির্বিজ্ঞানের সংখ্যা পেয়েছেন: পি

— রেমনার্টন

বা কম ক্রিপ্টিক ব্যবহার করুনgit push --force

— বেনেট ম্যাকএলউই

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

— ব্রায়ান ক্যাম্পবেল

দূরবর্তী রেপো ইতিহাস পুনরায় লেখার জন্য আমি -f এবং + বিকল্প উভয়ই চেষ্টা করেছি। উভয় বিকল্পে, আমি নন-ফাস্ট-ফরোয়ার্ড ইস্যুতে ছুটে এসেছি। [৫:০৫ পিএম] $ গিট পুশ-ফ উত্স স্থানীয়_এ: রিমোট_এ গণনা অবজেক্টস: 35, সম্পন্ন। 2 টি পর্যন্ত থ্রেড ব্যবহার করে ডেল্টা সংক্ষেপণ। সংক্ষিপ্ত অবজেক্টস: 100% (18/18), সম্পন্ন হয়েছে। লেখার অবজেক্টস: 100% (21/21), 7.41 কিবি, সম্পন্ন। মোট 21 (ব-দ্বীপ 9), পুনঃব্যবহৃত 0 (ব-দ্বীপ 0) রিমোট: ইতিহাস হারানো থেকে রোধ করার জন্য, দ্রুত-অগ্রসর হওয়া আপডেটগুলি প্রত্যাখ্যান করা হয়েছিল। পুনরায় চাপ দেওয়ার আগে দূরবর্তী পরিবর্তনগুলি (যেমন 'গিট টান') মার্জ করুন। বিশদটির জন্য 'গিট পুশ - হেল্প' বিভাগের 'ফাস্ট-ফরওয়ার্ডস সম্পর্কে নোট' দেখুন।

— শ্রীকান্ত

@ শ্রীকান্ত receive.denyNonFastForwardsকনফিগার বিকল্পের সাহায্যে জোর করে ধাক্কা পুরোপুরি অক্ষম করা সম্ভব । ভাগ করা সংগ্রহস্থলগুলিতে এই বিকল্পটি ডিফল্টরূপে সক্ষম হয়। সেক্ষেত্রে, যদি আপনি সত্যই সত্যই একটি জোর চাপতে চান তবে সর্বোত্তম বিকল্পটি হ'ল শাখাটি মুছে ফেলা এবং এটি দিয়ে পুনরায় তৈরি করা git push origin :remote_A; git push origin local_A:remote_A। তবে একটি ভাগ করা ভান্ডারগুলিতে এই ধরণের ওয়ার্কফ্লো করা কেন খারাপ ধারণা সম্পর্কে আমি উপরে যা লিখেছি তা পড়ুন। আপনি কেবল তখনই এটি করার চেষ্টা করা উচিত যদি আপনার এমন কিছু সমস্যা থাকে যা থেকে আপনি মুক্তি বা পুনর্লিখনের চেষ্টা করছেন এমন প্রতিশ্রুতিবদ্ধতায় গুরুতর সমস্যা দেখা দেয়।

— ব্রায়ান ক্যাম্পবেল

Answer 3

আপনাকে একটি করতে হতে পারে git pull, যা আপনার জন্য স্বতঃআপনার জিনিসগুলিকে মার্জ করে। তাহলে আপনি আবার প্রতিশ্রুতিবদ্ধ করতে পারেন। আপনার যদি দ্বন্দ্ব থাকে তবে তা সমাধান করার জন্য আপনাকে অনুরোধ জানাবে।

মনে রাখবেন, আপনি নির্দিষ্ট করতে যদি আপনার গিটকনফিগ আপডেট না করে থাকেন তবে আপনাকে কোন শাখাটি থেকে টানতে হবে তা নির্দিষ্ট করতে হবে ...

উদাহরণ স্বরূপ:

git pull origin develop:develop

Comments

এখনও নন-ফাস্ট-ফরোয়ার্ড সম্পর্কে উন্মাদ। এটিকে একীভূত করতে বাধ্য করার বিষয়ে কোনও চিন্তাভাবনা? ! [rejected] develop -> develop (non-fast-forward)

— rynmrtn

আমি মনে করি স্যুইচ -f তবে আমি ভুল হতে পারি। kernel.org/pub/software/scm/git/docs/git-pull.html

— টনি

এটি আংশিকভাবে কাজ করে। আমি গিথুব সম্পর্কিত আপডেটগুলি দেখছি না, যদিও এটি পূর্বের প্রতিশ্রুতিটি সর্বশেষ হিসাবে একটি হিসাবেও দেখায় git push origin develop)

— rynmrtn

Answer 4

আমি ইজিট ব্যবহার করছিলাম এবং আমিও এই সমস্যার মুখোমুখি হয়েছি। সবেমাত্র rebaseবর্তমান শাখায় চেষ্টা করেছি এবং এটি কাজ করেছে।