বৈশিষ্ট্য শাখা রিবেসের পরে গিট পুশ প্রত্যাখ্যান করা হয়েছে

916

ঠিক আছে, আমি ভেবেছিলাম এটি একটি সাধারণ গিট দৃশ্য, আমি কী মিস করছি?

আমার একটি masterশাখা এবং একটি featureশাখা আছে। আমি কিছু কাজ করি master, কিছু চালু করি featureএবং পরে আরও কিছু করি master। আমি এই জাতীয় কিছু দিয়ে শেষ করেছি (অভিধান সংক্রান্ত ক্রমটি কমিটের ক্রম বোঝায়):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

আমার git push origin masterরিমোটটি masterআপডেট রাখতে এবং আমার কাজের জন্য একটি রিমোট ব্যাকআপ বজায় রাখতে git push origin feature(কখন চালু হবে feature) কোনও সমস্যা নেই feature। এখন অবধি আমরা ভাল আছি।

তবে এখন আমি মাস্টারের featureউপরের কমিটগুলির উপরে পুনরায় শোধ করতে চাই F--G, তাই আমি git checkout featureএবং git rebase master। এখনও ভাল. এখন আমাদের আছে:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

সমস্যা: যে মুহুর্তে আমি নতুন রিবেসড featureব্রাঞ্চটি ব্যাকআপ করতে চাইছি git push origin feature, ধাক্কাটি প্রত্যাখ্যান করা হবে যেহেতু রিবেসিংয়ের কারণে গাছটি পরিবর্তিত হয়েছে। এটি কেবল সাথে সমাধান করা যেতে পারেgit push --force origin feature ।

আমি --forceএটি প্রয়োজন তা নিশ্চিত না করে ব্যবহার করে ঘৃণা করি। তো, আমার কি দরকার? রিবাজিং অগত্যা কি বোঝায় যে পরেরটি পুরো pushহওয়া উচিত --force?

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

git

— যুবাল আদম
সূত্র

681

সমস্যাটি এটি git pushধরে নিয়েছে যে দূরবর্তী শাখাটি আপনার স্থানীয় শাখায় দ্রুত-ফরওয়ার্ড করা যেতে পারে, এটি হ'ল স্থানীয় এবং দূরবর্তী শাখাগুলির মধ্যে সমস্ত পার্থক্য স্থানীয়ভাবে কিছু নতুন কমিটের শেষে থাকে যেমন:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

আপনি যখন git rebaseকমিট সম্পাদন করেন তখন ডি এবং ই প্রয়োগ করা হয় নতুন বেসে এবং নতুন কমিট তৈরি হয়। এর অর্থ রিবেস করার পরে আপনার এর মতো কিছু রয়েছে:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

এই পরিস্থিতিতে দূরবর্তী শাখাটি স্থানীয় কাছে দ্রুত ফরোয়ার্ড করা যাবে না। যদিও, তাত্ত্বিকভাবে স্থানীয় শাখাটি দূরবর্তীতে একত্রীকরণ করা যেতে পারে (স্পষ্টত আপনার সেই ক্ষেত্রে এটির দরকার নেই), তবে হিসাবেgit push কেবল দ্রুত-ফরোয়ার্ড সম্পাদন করলে এটি ছুঁড়ে যায় ত্রুটি।

এবং কোন --forceবিকল্পটি কেবলমাত্র দূরবর্তী শাখার অবস্থাকে উপেক্ষা করা এবং আপনি যে প্রতিশ্রুতি দিচ্ছেন তাতে সেটি সেট করা। তাই git push --force origin feature-branchকেবল origin/feature-branchস্থানীয় সাথে ওভাররাইড করে feature-branch।

আমার মতে, বৈশিষ্ট্য শাখাগুলিকে রিবাইজ করা masterএবং তাদেরকে জোর করে রিমোট রিপোজিটরিতে ফিরিয়ে দেওয়া ঠিক আছে যতক্ষণ না আপনি সেই শাখায় কাজ করা একমাত্র ব্যক্তি।

— কেএল -7
সূত্র

67

সত্যি কথা বলতে, ফিচার শাখার মূল সংস্করণটিকে রিজেড এক প্রান্তে টানা এবং মার্জ করা রিবেসিংয়ের পুরো ধারণাটিকে মুছে দেয়।

— কেএল -7

24

হয়তো আমি আপনাকে সঠিকভাবে বুঝতে পারি নি, তবে আপনি যদি বৈশিষ্ট্য শাখাটি টানেন তবে তা তাজা মাস্টার শাখায় পুনরায় চালু করুন, আপনি জোর করে এটিকে পিছনে ঠেলাতে পারবেন না, কারণ বৈশিষ্ট্য শাখার দূরবর্তী সংস্করণটি আপনার নতুনটিতে দ্রুত পাঠানো যাবে না বৈশিষ্ট্য শাখার (প্রত্যাবর্তিত) সংস্করণ। ওপি তাঁর প্রশ্নে ঠিক এটাই বর্ণনা করেছেন। যদি রিবেজিংয়ের পরে, তবে ধাক্কা দেওয়ার আগে আপনি করেন git pull feature-branch, এই টানাটি নতুন মার্জ কমিট তৈরি করবে (বৈশিষ্ট্য শাখার দূরবর্তী এবং স্থানীয় সংস্করণগুলিকে মার্জ করে)। সুতরাং হয় আপনি রিবাইজ করার পরে একটি অপ্রয়োজনীয় মার্জ পান, বা আপনি এটির সাথে চাপ দিন --force।

— কেএল -7

6

আহ, আমি মনে করি এটি পেয়েছি। আপনি মার্ক লংগায়ারের উত্তরের মতো একই পদ্ধতির বর্ণনা দিচ্ছেন। তবে এটি মার্জ কমিট জেনারেট করে না। এটি কিছু ক্ষেত্রে কার্যকর হতে পারে তবে আমি নিজের বৈশিষ্ট্য শাখাগুলিতে বেশিরভাগ রিবেস ব্যবহার করি (সুতরাং push --forceকোনও সমস্যা নয়) কোনও লেনদেন না করেই ইতিহাস রৈখিক রচনার জন্য keep

— কেএল -7

11

"ফোর্স-পুশ" এর সমস্যাটি হ'ল আপনি "stuffিলে stuffালা জিনিস" (পূর্বের কমিট) করতে পারেন, এটি সাধারণত কোনও সংস্করণ নিয়ন্ত্রণ সিস্টেমে কখনও সম্ভব না হওয়া উচিত should সেই কারণে কমপক্ষে একটি "মাস্টার-ইশ" শাখা থাকা উচিত সম্ভাব্য ক্ষতি সীমাবদ্ধ করার জন্য, জোর-ধাক্কা গ্রহণ না করার সেটিংস । (নিম্নলিখিতগুলির মধ্যে কোনওটির নাম দিন: ভ্রষ্ট / বরখাস্ত কর্মচারী, নিজস্ব বোকা, ক্লান্ত ও অধিক কাজ 'সিদ্ধান্ত' ...)।

— ফ্র্যাঙ্ক নোক

13

--force-with-leaseযেমন @ হারদেব প্রস্তাবিত একটি দুর্দান্ত বিকল্প

— অগাস্টারসউজা

464

পরিবর্তে -f বা --for বিকাশকারীদের ব্যবহার করা উচিত

--force-with-lease

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

— Hardev
সূত্র

33

দুর্দান্ত ব্যাখ্যা। git push --force-with-leaseআমাকে একগুচ্ছ বাঁচিয়েছে

— ckib16

5

এটি একটি দরকারী মন্তব্য, কিন্তু আসলেই প্রশ্নের উত্তর নয়।

— ডালিন

4

এটি উত্তর, মাস্টারকে প্রত্যাবর্তন / বিকাশ একটি সমস্যা তৈরি করে, ঠিক এই কারণেই - বলিউডের সাথে-ইজারা বিদ্যমান।

— তামির ড্যানিয়েলি

3

এটি গ্রহণযোগ্য উত্তর হওয়া উচিত। ঠিক বর্ণিত সমস্যাটি সমাধান করে - এর মধ্যে অন্য কেউ প্রতিশ্রুতিবদ্ধ হলে জোর করে চাপ দেওয়া জোর করে force

— লুজিয়ান

3

আমি মনে করি গৃহীত উত্তর এবং এই দুটি প্রশ্নের সমাধান করে। গৃহীত উত্তরটি আপনাকে জোর করার প্রয়োজন কেন তা ব্যাখ্যা করে। এবং এটি ব্যাখ্যা করে কেন --force-with-leaseব্যবহারের উদ্বেগকে সম্বোধন করে--force

— জেফ অ্যাপেরেটি

47

আমি পরিবর্তে "চেকআউট-বি" ব্যবহার করব এবং এটি বোঝা সহজ।

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

আপনি যখন মুছবেন তখন আপনি একটি বহির্গমন শাখায় ঠেলা ঠেকাতে পারবেন যার মধ্যে বিভিন্ন SHA আইডি রয়েছে। আমি এক্ষেত্রে কেবল দূরবর্তী শাখা মুছে ফেলছি।

— এডি হার্নান্দেজ
সূত্র

6

এটি দুর্দান্ত কাজ করে, বিশেষত যদি আপনার দলে গিট হুক থাকে যা সমস্ত গিট পুশ - ফোর্স কমান্ডকে প্রত্যাখ্যান করে।

— রায়ান টেমস

1

ধন্যবাদ যে এটি ভালভাবে কাজ করেছে। এখানে আরও বিস্তারিত জানার জন্য আমি আরও ভালভাবে বুঝতে পারি। আপনি যখন ফোর্স পুশ করতে না চান বা করতে না পারেন তখন এটি খুব কার্যকর। রিমোট শাখা এবং রিবেসিং

— রাজকন

5

এর একই ফলাফল রয়েছে, তবে push --forceগিট রেপো প্রতিরোধকারী কেবলমাত্র একটি উপায় --force। যেমনটি, আমি মনে করি না যে এটি কখনও একটি ভাল ধারণা - হয় রেপো অনুমতি দেয় push --force, বা কোনও ভাল কারণে এটি এটি অক্ষম করে। --forceরিমোট রেপোতে অক্ষম থাকলে নবির উত্তরটি আরও বেশি উপযুক্ত , কারণ এতে অন্যান্য বিকাশকারীদের কাছ থেকে কমান্ড হারানো বা অন্যথায় সমস্যা সৃষ্টির ঝুঁকি থাকে না।

— লোগান পিকআপ

19

এর একটি সমাধান হ'ল এমএসজিগিতের রিবিসিং মার্জ স্ক্রিপ্টটি যা করে - রিবেসের পরে, এর featureসাথে পুরানো মাথার সাথে একীভূত হয় -s ours। আপনি প্রতিশ্রুতি গ্রাফ দিয়ে শেষ:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... এবং আপনার ধাক্কা featureদ্রুত অগ্রসর হবে।

অন্য কথায়, আপনি এটি করতে পারেন:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(পরীক্ষিত নয়, তবে আমি মনে করি এটি সঠিক ...)

— মার্ক লংগায়ার
সূত্র

26

আমি বিশ্বাস করি যে ব্যবহারের সর্বাধিক সাধারণ কারণ git rebase( masterআপনার বৈশিষ্ট্য শাখায় ফিরে যাওয়ার পরিবর্তে ) পরিষ্কার রৈখিক ইতিহাস তৈরি করে। আপনার পদ্ধতির সাথে ইতিহাস আরও খারাপ হয়ে যায়। এবং যেহেতু রিবিসিং তাদের পূর্ববর্তী সংস্করণগুলির কোনও রেফারেন্স ছাড়াই নতুন কমিট তৈরি করে আমি এই বিষয়ে নিশ্চিত না যে এই সংযুক্তির ফলাফল পর্যাপ্ত হবে।

— কেএল -7

6

@ কেএল -7: পুরো বিষয়টিটি merge -s oursহ'ল এটি কৃত্রিমভাবে পূর্ববর্তী সংস্করণটিতে পিতামাতার রেফারেন্স যুক্ত করে। অবশ্যই, ইতিহাসটি পরিষ্কার দেখাচ্ছে না, তবে featureশাখাটি চাপ দেওয়ার জন্য প্রশ্নকর্তাকে বিশেষত বিরক্ত করা হয়েছে বলে মনে হয় এবং এটি তার কাছাকাছি চলে যায়। আপনি যদি রিবেস করতে চান তবে এটি একটি বা অন্যটি কম-বেশি। :) আরও সাধারণভাবে, আমি মনে করি এটি মজার বিষয় যে মাইক্রিট প্রকল্পটি এটি করে ....

— লংগায়ার

@ কেএল -7: ঘটনাচক্রে, আমি আপনার উত্তরটি +1 করেছি, যা স্পষ্টভাবে সঠিক one আমি কেবল ভেবেছিলাম এটি খুব আকর্ষণীয়ও হতে পারে।

— লংগায়ার

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

— কেএল -7

15

এটি হতে পারে বা নাও হতে পারে যে এই শাখায় কেবলমাত্র একজন বিকাশকারী রয়েছেন, এটি এখন (পুনর্বাসনের পরে) মূল / বৈশিষ্ট্যের সাথে সামঞ্জস্য নয়।

এই হিসাবে আমি নিম্নলিখিত ক্রমটি ব্যবহার করার পরামর্শ দেব:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

হ্যাঁ, নতুন শাখা, এটি - ফোর্স ছাড়াই এটিকে সমাধান করা উচিত, যা আমি মনে করি সাধারণত একটি বড় গিট ডিসব্রাক।

— JAR.JAR.beans
সূত্র

3

বলার জন্য দুঃখিত তবে: "বিদ্যমান শাখাগুলি বলপূর্বক অগ্রাহ্য করা এড়াতে" শাখা উত্পন্ন করে রাখুন "- নিঃসঙ্গ বৈশিষ্ট্য বিকাশকারীদের" (যে ওভাররাইড করতে পারে) বা বৈশিষ্ট্য শাখায় কাজ করা একাধিক লোককে (সেই শাখাকে "বৃদ্ধি" এবং কথা বলার দরকার নেই) লোকেরা যেতে হবে) - এটি সংস্করণ পদ্ধতির মধ্যে ম্যানুয়াল সংস্করণ ("থিসিস_00.ডোক, থিসিস_01.ডোক, ...") এর মতো ...

— ফ্রাঙ্ক নোক

2

এছাড়াও, আপনি যখন একটি শাখার নামে গিথুব পিআর খোলেন, এটি আপনাকে সাহায্য করবে না, আপনি যে নতুন শাখার নাম দিয়েছিলেন তার জন্য একটি নতুন পিআর তৈরি করতে হবে।

— gprasant

1

আমার অভিজ্ঞতা থেকে @ ফ্রাঙ্কি অর্ধেক সত্য। একাকী বিকাশকারী, হ্যাঁ, জোর করে চাপ দেওয়া যথেষ্ট সহজ, তবে এটি এমন অভ্যাস যা পরে আপনাকে কামড়াতে পারে। একটি নতুন দেব সদ্য যোগদান করেছেন? অথবা সম্ভবত এমন কিছু সিআই সিস্টেম রয়েছে যা --হার্ড রিসেট ব্যবহার করছে না? একটি দলকে সহযোগিতা করার জন্য, আমি মনে করি যে নতুন শাখার নামটি যোগাযোগ করা যথেষ্ট সহজ, এটি সহজেই স্ক্রিপ্টও করা যেতে পারে + একটি দলের জন্য, আমি স্থানীয়ভাবে পুনর্বাসনের পরামর্শ দিই বা যখন শাখাটি মার্জ করার জন্য প্রস্তুত থাকে, দিনের কাজের সময় নয় not , অতিরিক্ত প্রতিশ্রুতি ফলস্বরূপ পুনর্বাসনা / মার্জ সংঘাতের সাথে মোকাবিলা করার চেয়ে কোনও ঝামেলা কম।

— JAR.JAR.beans

পিআর এর জন্য @gprasant, আবারও, আমি মনে করি এটি রিবেস করা ভুল হবে, আমি পিআর ঠিক করে একক প্রতিশ্রুতি দেখতে চাই। একটি রিবাজ (স্কোয়াশ) কেবল পরে মাস্টারগুলিতে সংযুক্তির অংশ হিসাবে ঘটতে হবে এবং যখন পিআর সব সম্পন্ন এবং প্রস্তুত হয় (সুতরাং কোনও নতুন পিআর খোলার দরকার নেই)।

— JAR.JAR.beans

13

ফোর্স পুশ এড়ানো আমার উপায় হ'ল একটি নতুন শাখা তৈরি করা এবং সেই নতুন শাখায় কাজ চালিয়ে যাওয়া এবং কিছুটা স্থিতিশীলতার পরে, পুরাতন শাখাটি পুনর্বাসিত করা অপসারণ:

স্থানীয়ভাবে চেক আউট শাখাটি মুক্তি দেওয়া
রিবেসড শাখা থেকে নতুন শাখায় শাখা
রিমোটে নতুন শাখা হিসাবে সেই শাখাটি পুশ করছে। এবং রিমোটে পুরানো শাখা মুছে ফেলা হচ্ছে

— নবীর
সূত্র

1

কেন এই বিকল্পের জন্য কোন ভালবাসা? এটি অবশ্যই সবচেয়ে পরিষ্কার, সহজতম, নিরাপদ।

— সিডিএমও

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

— তামির ড্যানিয়েলি

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

— নবী

2

@ নবী ঠিক এটিই করেছেন - জোর-ইজারা-ইজারাটি ব্যতীত, এটি ছাড়াও এটি যাচাই করে যে কোনও নতুন প্রতিশ্রুতি আপনার নয়।

— তামির ড্যানিয়েলি

12

অন্যরা আপনার প্রশ্নের উত্তর দিয়েছে। আপনি যদি একটি শাখা পুনরায় চালু করেন তবে আপনাকে সেই শাখাটি ধাক্কা দিতে বাধ্য করতে হবে।

রিবেস এবং একটি ভাগ করা সংগ্রহস্থল সাধারণত একসাথে হয় না। এটি ইতিহাস রাইটিং। অন্যরা যদি সেই শাখা ব্যবহার করে বা branch শাখা থেকে ব্রাঞ্চ করে থাকে তবে পুনর্বাসনটি বেশ অপ্রীতিকর হবে।

সাধারণভাবে, রিবেস স্থানীয় শাখা পরিচালনার জন্য ভাল কাজ করে। রিমোট শাখা পরিচালনা সুস্পষ্ট মার্জ (--no-ff) এর সাথে সবচেয়ে ভাল কাজ করে।

আমরা মাস্টারকে কোনও বৈশিষ্ট্য শাখায় মার্জ করাও এড়াব। পরিবর্তে আমরা মাস্টারকে রিবেস করি তবে একটি নতুন শাখার নাম সহ (যেমন একটি সংস্করণ প্রত্যয় যুক্ত)। এটি ভাগ করা সংগ্রহস্থলে রিবেসিংয়ের সমস্যা এড়ায়।

— বিল ডোর
সূত্র

5

আপনি একটি উদাহরণ যোগ করতে পারেন দয়া করে?

— থার্মেক

8

একটি দিয়ে ভুল কি git merge masterউপর featureশাখা? এটি মেইনলাইন শাখা থেকে পৃথক রাখার সময় আপনার কাজটি সংরক্ষণ করবে।

A--B--C------F--G
       \         \
        D--E------H

সম্পাদনা: আহ দুঃখিত আপনার সমস্যা বিবৃতিটি পড়েনি। আপনি একটি সঞ্চালন হিসাবে আপনার শক্তি প্রয়োজন হবে rebase। ইতিহাসটি সংশোধন করে এমন সমস্ত কমান্ডের --forceআর্গুমেন্টের প্রয়োজন হবে । আপনাকে কাজ হারাতে বাধা দেওয়ার জন্য এটি একটি ব্যর্থ সাফ (পুরানো Dএবং Eহারিয়ে যাবে)।

সুতরাং আপনি এমন একটি পরিবেশনা git rebaseকরেছেন যা গাছটিকে দেখতে চেহারা তৈরি করেছে (যদিও আংশিকভাবে এটি লুকানো রয়েছে Dএবং Eনামযুক্ত শাখায় আর নেই):

A--B--C------F--G
       \         \
        D--E      D'--E'

সুতরাং, আপনার নতুন featureশাখাটি (এটি সহ D'এবং এর E'মধ্যে) ঠেলে দেওয়ার সময় আপনি হারাবেন Dএবং E।

— Bouke
সূত্র

3

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

— যুবাল আদম

4

আমার জন্য অনুসরণ করা সহজ পদক্ষেপগুলি কাজ করে:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

উপরের সমস্ত কাজ করার পরে, আমরা নিম্নলিখিত আদেশটি অনুসরণ করে মাই ফিচার শাখাটি মুছতে পারি:

git push origin --delete myFeature

— নীরজ খেদে
সূত্র

3

নিম্নলিখিতটি আমার পক্ষে কাজ করে:

git push -f origin branch_name

এবং এটি আমার কোনও কোড সরিয়ে দেয় না।

তবে, আপনি যদি এড়াতে চান তবে নিম্নলিখিতগুলি করতে পারেন:

git checkout master
git pull --rebase
git checkout -b new_branch_name

তারপরে আপনি নতুন শাখায় আপনার সমস্ত প্রতিশ্রুতি চেরি-বাছাই করতে পারেন। git cherry-pick COMMIT ID এবং তারপরে আপনার নতুন শাখা টিপুন।

— সোহায়ের আহমদ
সূত্র

5

-fএটি একটি উপনাম --force, যা সম্ভব হলে যদি প্রশ্নটি এড়াতে চাইছে।

— এপোচেনগাইন

1

ওপি সমস্যাটি বুঝতে পারে না, কেবল একটি ভাল সমাধানের সন্ধান করে ...

এটি একটি অনুশীলন হিসাবে কিভাবে?

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

এই পদ্ধতির জন্য ইতিমধ্যে একটি প্যাটার্নের নাম থাকতে পারে।

— ফ্র্যাঙ্ক নোক
সূত্র