গিট রিবেস - আন্টোর আচরণ আমি বুঝতে পারি না

Question

আমি লক্ষ্য করেছি যে নিম্নলিখিত গিট কমান্ডের দুটি ব্লকের বিভিন্ন আচরণ রয়েছে এবং কেন তা আমি বুঝতে পারি না।

আমার একটি Aএবং একটি Bশাখা রয়েছে যা দিয়ে আলাদা হয়commit

---COMMIT--- (A)
\
 --- (B)

আমি সর্বশেষে Bশাখাটি পুনরায় চালু করতে চাই A(এবং Bশাখায় প্রতিশ্রুতিবদ্ধ থাকতে পারি)

---COMMIT--- (A)
         \
          --- (B)

আমি যদি করি তবে কোন সমস্যা নেই:

checkout B
rebase A

তবে আমি যদি:

checkout B
rebase --onto B A

এটি মোটেও কাজ করে না, কিছুই হয় না। আমি বুঝতে পারছি না কেন দুটি আচরণ আলাদা।

পিএইচপিস্টর্ম গিট ক্লায়েন্ট দ্বিতীয় সিনট্যাক্স ব্যবহার করে এবং তাই আমার কাছে সম্পূর্ণ বিচ্ছিন্ন বলে মনে হয়, এজন্যই আমি এই সিনট্যাক্স ইস্যুটির জন্য জিজ্ঞাসা করি।

Comments

git-scm.com/book/ch3-6.html

— choroba

Answer 1

TL; ড

আপনার ক্ষেত্রে ব্যবহারের Bশীর্ষে রিবেস করার সঠিক বাক্য গঠন :Agit rebase --onto

git checkout B
git rebase --onto A B^

বা রি-বেসের ফলে Bশীর্ষে Aথেকে শুরু কমিট যে পিতা বা মাতা হলB সঙ্গে রেফারেন্সড B^বা B~1।

আপনি যদি এর মধ্যে পার্থক্যটি আগ্রহী হন git rebase <branch>এবং git rebase --onto <branch>পড়ুন।

দ্য কুইক: গিট রিবেস

git rebase <branch>শাখা আপনি বর্তমানে চেক আউট করেছি, দ্বারা সমর্থিত রি-বেসের ফলে যাচ্ছে HEAD, শীর্ষ উপর সর্বশেষ কমিট যে যোগাযোগ করা যাবে থেকে <branch>কিন্তু না থেকে HEAD।
এটি প্রত্যাবর্তনের সবচেয়ে সাধারণ ঘটনা এবং তর্কসাপেক্ষে এটির জন্য সামনের পরিকল্পনা কম প্রয়োজন।

          Before                           After
    A---B---C---F---G (branch)        A---B---C---F---G (branch)
             \                                         \
              D---E (HEAD)                              D---E (HEAD)

এই উদাহরণে, Fএবং Gএমন কমিটগুলি রয়েছে যেগুলি থেকে পৌঁছানো যায় branchতবে আসে না HEAD। বলছে git rebase branchনিতে হবে D, হয় যে প্রথম শাখাবিন্যাস বিন্দু পরে কমিট, এবং এটা রি-বেসের ফলে (অর্থাত তার পিতা বা মাতা পরিবর্তন ) সর্বশেষ উপরে কমিট থেকে পৌঁছানো branchকিন্তু থেকে HEAD, যে G।

যথার্থ: গিট রিবেস - 2 তর্ক যুক্তি দিয়ে

git rebase --ontoআপনাকে একটি নির্দিষ্ট কমিট থেকে শুরু করে রিবেস করতে দেয় । এটি আপনাকে কী রিবেস করা হচ্ছে এবং কোথায় হচ্ছে তার সঠিক নিয়ন্ত্রণ দেয়। এটি এমন দৃশ্যের জন্য যেখানে আপনার সুনির্দিষ্ট হওয়া দরকার।

উদাহরণস্বরূপ, আসুন কল্পনা করুন যে শুরু থেকে আমাদের HEADউপরে অবিকল পুনঃবারণ প্রয়োজন । আমরা কেবল আমাদের কার্যকারী শাখায় আনতে আগ্রহী যখন একই সময়ে আমরা রাখতে চাই না কারণ এতে কিছুটা বেমানান পরিবর্তন রয়েছে।FEFD

          Before                           After
    A---B---C---F---G (branch)        A---B---C---F---G (branch)
             \                                     \
              D---E---H---I (HEAD)                  E---H---I (HEAD)

এই ক্ষেত্রে, আমরা বলব git rebase --onto F D। এর অর্থ:

রি-বেসের ফলে থেকে পৌঁছানো কমিট HEADযার পিতা বা মাতা হল Dউপরে F।

অন্য কথায়, পিতা বা মাতা পরিবর্তন এর Eথেকে Dথেকে F। এর সিনট্যাক্সটি git rebase --ontoতখন git rebase --onto <newparent> <oldparent>।

আর একটি দৃশ্য যেখানে এটি কার্যকর হয় তা হ'ল আপনি যখন ইন্টারেক্টিভ রিবেস না করেই বর্তমান শাখা থেকে কিছু কমিট দ্রুত সরিয়ে ফেলতে চান :

          Before                       After
    A---B---C---E---F (HEAD)        A---B---F (HEAD)

এই উদাহরণস্বরূপ, সারণিটি সরিয়ে ফেলতে Cএবং Eক্রম থেকে আপনি বলবেন git rebase --onto B Eবা পুরানো পিতা বা মাতা যেখানে ছিলেন তার HEADউপরে পুনরায় সরিয়ে ফেলুন ।BE

সার্জন: গিট রিবেস - 3 টি আর্গুমেন্ট সহ

git rebase --ontoনির্ভুলতার দিক থেকে আরও একধাপ এগিয়ে যেতে পারে। প্রকৃতপক্ষে, এটি আপনাকে অন্য একের শীর্ষে কমিটসগুলির একটি স্বেচ্ছাসেবী সীমাটি পুনরায় চালু করতে দেয়।

এখানে একটি উদাহরণ:

          Before                                     After
    A---B---C---F---G (branch)                A---B---C---F---G (branch)
             \                                             \
              D---E---H---I (HEAD)                          E---H (HEAD)

এই ক্ষেত্রে, আমরা বর্তমানে দিকে ইশারা দিচ্ছি তা উপেক্ষা E---Hকরে উপরে সঠিক রেঞ্জটি পুনরায় চালু করতে চাই। আমরা এটি করে বলতে পারি , যার অর্থ:FHEADgit rebase --onto F D H

করে যার পিতা বা মাতা হয় পরিসীমা রি-বেসের ফলে Dপর্যন্ত Hশীর্ষে F।

কমিটের git rebase --ontoএকটি ব্যাপ্তির সাথে সিনট্যাক্সটি হয়ে যায় git rebase --onto <newparent> <oldparent> <until>। কৌতুক এখানে স্মরণ করা হয় যে, দ্বারা সমর্থিত কমিট <until>করা হয় অন্তর্ভুক্ত সীমার মধ্যে এবং নতুন হয়ে যাবে HEADপর রি-বেসের ফলে সম্পূর্ণ।

Comments

চমৎকার উত্তর. সাধারণ ক্ষেত্রে কেবল একটি সামান্য সংযোজন: <oldparent>রেঞ্জের দুটি অংশ বিভিন্ন শাখায় থাকলে নামটি ভেঙে যায়। সাধারণত এটি: "যেগুলি প্রতিশ্রুতি আসতে পারে তার অন্তর্ভুক্ত করুন <until>তবে যেগুলি প্রতিশ্রুতিবদ্ধ তা প্রতিশ্রুতিবদ্ধ <oldparent>।"

— musiKk

git rebase --onto <newparent> <oldparent>- আমি যে আচরণ দেখেছি তার সবচেয়ে ভাল ব্যাখ্যা!

— রনকোট

ধন্যবাদ! আমি কিন্ডা --ontoবিকল্পের সাথে লড়াই করে যাচ্ছিলাম তবে এটি স্ফটিক স্পষ্ট করে দিয়েছে! আমি এটি আগেও বুঝতে পারি না কীভাবে: ডি 'চমত্কার "টিউটোরিয়াল" :-) জন্য ধন্যবাদ

— গ্রেঙ্গর

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

— খেলুন

এটি সহায়ক ছিল। ম্যান পেজটি যুক্তিগুলি মোটেও ব্যাখ্যা করে না।

— a544jh

Answer 2

এটি বুঝতে আপনার যা প্রয়োজন তা কেবল --onto:

git rebase --onto <newparent> <oldparent>

আপনি একটি প্রতিশ্রুতিবদ্ধ হিসাবে একটি পিতামাতার স্যুইচিং করা হয়, কিন্তু আপনি প্রতিশ্রুতি এর শে প্রদান করে না, শুধুমাত্র তার বর্তমান (পুরানো) পিতামাতার শে।

Comments

সংক্ষিপ্ত এবং সহজ আসলে, বুঝতে পেরেছি যে সেই প্রতিশ্রুতির পরিবর্তে আমি যেটিকে পুনঃস্থাপন করতে চাই তার প্রতি আমার পিতামাতার প্রতিশ্রুতি প্রদান করতে আমার দীর্ঘ সময় নিয়েছে।

— আন্তোনিওসেস

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

— ত্রিসমেজিস্টোস

দ্রষ্টব্য: আপনাকে শাখায় থাকতে হবে, বা শাখার নামটি 3 য় প্যারামিটার গিট রিবেস হিসাবে যুক্ত করতে হবে --আর <নতুন স্বামী> << স্বামী> <বৈশিষ্ট্য- ব্র্যাঞ্চ>

— জেসন পোর্টনাই

এই উত্তরটি আশ্চর্যজনক, সরাসরি এই থ্রেডে প্রয়োজনীয় বিন্দুতে

— জন কালভিনার

Answer 3

শীঘ্রই রাখুন, দেওয়া:

      Before rebase                             After rebase
A---B---C---F---G (branch)                A---B---C---F---G (branch)
         \                                         \   \
          D---E---H---I (HEAD)                      \   E'---H' (HEAD)
                                                     \
                                                      D---E---H---I

git rebase --onto F D H

যা একই (যেমন --ontoএকটি যুক্তি নেয়):

git rebase D H --onto F

পদ্ধতি সীমার মধ্যে করে রি-বেসের ফলে (ডি, এইচ] এফ নোটিশ উপরে পরিসর বাঁদিকের একচেটিয়া। এটা একচেটিয়া কারণ এটা উল্লেখ করার 1st টাইপিং যেমন দ্বারা কমিট সহজ branchযাক git1 ম এটি চলেনি থেকে কমিট branchঅর্থাত Dযা বাড়ে H।

ওপি কেস

    o---o (A)
     \
      o (B)(HEAD)

git checkout B
git rebase --onto B A

একক কমান্ডে পরিবর্তন করা যেতে পারে:

git rebase --onto B A B

এখানে ত্রুটির মতো যা দেখায় Bতা হ'ল এর অর্থ হল "কিছু শৃঙ্খলা সরিয়ে নিন যা Bশীর্ষে শাখা নিয়ে যায় B"। প্রশ্নগুলি "কিছু প্রতিশ্রুতিবদ্ধ" কী তা। আপনি -iপতাকা যুক্ত করলে দেখতে পাবেন এটি একক প্রতিশ্রুতি দ্বারা নির্দেশিত HEAD। কমিট হয় এড়ানো কারণ এটি ইতিমধ্যেই প্রয়োগ করা হয় --ontoলক্ষ্য Bএবং তাই কিছুই ঘটবে।

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

এর আরও ব্যাখ্যা এবং এর প্রযোজ্য ব্যবহার git rebase <upstream> <branch> --onto <newbase>।

git rebase পূর্ব নির্ধারিত.

git rebase master

হয় প্রসারিত:

git rebase --onto master master HEAD
git rebase --onto master master current_branch

পুনর্বাসনের পরে স্বয়ংক্রিয় চেকআউট।

যখন স্ট্যান্ডার্ড উপায়ে ব্যবহৃত হয়, যেমন:

git checkout branch
git rebase master

আপনি লক্ষ্য করবেন না যে রিবেস সর্বাধিক সাম্প্রতিক রিবাসেড কমিটগুলিতে gitচলে আসে branchএবং করে git checkout branch( git reflogইতিহাস দেখুন)। মজার বিষয় যখন 2 য় আর্গুমেন্টটি হ্যাশ করার পরিবর্তে শাখার নাম রিবেস এখনও কাজ করে তবে সরানোর কোনও শাখা নেই যাতে আপনি "বিচ্ছিন্ন হেড" এ চলে যান পরিবর্তে সরানো শাখায় চেক আউট করে।

প্রাইমারি প্রসারিত কমিটগুলি ছাড়ুন।

masterমধ্যে --onto1 ম থেকে নেওয়া হয় git rebaseযুক্তি।

                   git rebase master
                              /    \
         git rebase --onto master master

সুতরাং ব্যবহারিকভাবে এটি অন্য কোনও অঙ্গীকার বা শাখা হতে পারে। এইভাবে আপনি সাম্প্রতিকতমগুলি গ্রহণ করে এবং প্রাথমিক ডাইভার্ড করা কমিটগুলি রেখে রিবেস কমিটের সংখ্যা সীমাবদ্ধ করতে পারেন।

git rebase --onto master HEAD~
git rebase --onto master HEAD~ HEAD  # Expanded.

রি-বেসের ফলে হবে একক দ্বারা সরু কমিট HEADকরতে masterএবং "বিচ্ছিন্ন মাথা" শেষ পর্যন্ত।

সুস্পষ্ট চেকআউটগুলি এড়িয়ে চলুন।

ডিফল্ট HEADবা current_branchতর্কটি প্রাসঙ্গিকভাবে আপনি যে জায়গা থেকে নিয়েছেন সেখান থেকে নেওয়া হয়েছে This এ কারণেই বেশিরভাগ লোকেরা সেই শাখায় চেকআউট করে যা তারা পুনরায় শোধ করতে চায়। কিন্তু যখন ২ য় রিবাজে আর্গুমেন্ট সুস্পষ্টভাবে দেওয়া হয় তখন আপনাকে রিবায়েসকে অন্তর্নিহিত উপায়ে পাস করার আগে চেকআউট করতে হবে না।

(branch) $ git rebase master
(branch) $ git rebase master branch  # Expanded.
(branch) $ git rebase master $(git rev-parse --abbrev-ref HEAD)  # Kind of what git does.

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

(master) $ git rebase master branch
(branch) $ # Rebased. Notice checkout.

Answer 4

সহজ ভাবে বললে, git rebase --ontoকরে একটি সীমার নির্বাচন করে এবং তাদের rebases উপর প্যারামিটার হিসাবে দেওয়া কমিট।

ম্যান পেজগুলি পড়ুন git rebase, "উপর" অনুসন্ধান করুন। উদাহরণগুলি খুব ভাল:

example of --onto option is to rebase part of a branch. If we have the following situation:

                                   H---I---J topicB
                                  /
                         E---F---G  topicA
                        /
           A---B---C---D  master

   then the command

       git rebase --onto master topicA topicB

   would result in:

                        H'--I'--J'  topicB
                       /
                       | E---F---G  topicA
                       |/
           A---B---C---D  master

এই ক্ষেত্রে আপনি থেকে করে রি-বেসের ফলে করার Git বলতে topicAকরার জন্য topicBউপরে master।

Answer 5

এর মধ্যে পার্থক্যটি আরও ভালভাবে বুঝতে git rebaseএবং git rebase --ontoউভয় আদেশের সম্ভাব্য আচরণগুলি কী তা জেনে রাখা ভাল। git rebaseআমাদের কমিটগুলি নির্বাচিত শাখার শীর্ষে স্থানান্তরিত করার অনুমতি দিন। এখানকার মত:

git rebase master

এবং ফলাফল:

Before                              After
A---B---C---F---G (master)          A---B---C---F---G (master)
         \                                           \
          D---E (HEAD next-feature)                   D'---E' (HEAD next-feature)

git rebase --ontoআরও স্পষ্টতা। এটি আমাদের সুনির্দিষ্ট প্রতিশ্রুতি চয়ন করতে দেয় যেখানে আমরা শুরু করতে চাই এবং যেখানে আমরা শেষ করতে চাই। এখানকার মত:

git rebase --onto F D

এবং ফলাফল:

Before                                    After
A---B---C---F---G (branch)                A---B---C---F---G (branch)
         \                                             \
          D---E---H---I (HEAD my-branch)                E'---H'---I' (HEAD my-branch)

আরও বিশদ পাওয়ার জন্য আমি আপনাকে গিট রিবেস --অ্যান্ট ওভারভিউ সম্পর্কে আমার নিজের নিবন্ধটি পরীক্ষা করে দেখার পরামর্শ দিচ্ছি

Comments

@ ম্যাক্যেন শিওর, ভবিষ্যতে আমি এটি মনে

— রাখব

সুতরাং, আমরা পড়তে পারেন git rebase --onto F Dহিসাবে এফ যেমন ডি এর পিতা বা মাতা সেট শিশু , আমরা না করতে পারেন?

— প্রথম

Answer 6

আপনার জন্য ontoদুটি অতিরিক্ত শাখা প্রয়োজন। যে কমান্ড দিয়ে আপনি করে থেকে আবেদন করতে পারেন branchBযে এর উপর ভিত্তি করে branchAঅন্য শাখা যেমন সম্মুখের master। নমুনা নীচে সালে branchBউপর ভিত্তি করে তৈরি branchAএবং আপনার পরিবর্তনগুলি প্রয়োগ করার বিষয়ে branchBউপর masterপরিবর্তন প্রয়োগ ছাড়া branchA।

o---o (master)
     \
      o---o---o---o (branchA)
                   \
                    o---o (branchB)

কমান্ড ব্যবহার করে:

checkout branchB
rebase --onto master branchA 

আপনি নিম্নলিখিত প্রতিশ্রুতিবদ্ধ শ্রেণিবদ্ধতা পাবেন।

      o'---o' (branchB)
     /
o---o (master)
     \
      o---o---o---o (branchA)

Comments

আপনি কি দয়া করে আরও কিছু ব্যাখ্যা করতে পারেন, আমরা যদি মাস্টারকে পুনর্বাসনা করতে চাই তবে এটি কীভাবে বর্তমান শাখায় পরিণত হয়? আপনি যদি তা করেন rebase --onto branchA branchBতবে পুরো মাস্টার শাখাটি ব্রাঞ্চএর মাথায় রাখবে?

— পলিমারেজ

এই হওয়া উচিত নয় checkout branchB: rebase --onto master branchA?

— সোনাররাটিও

কেন এই upvated হয়েছে? এটি এটি যা বলে তা করে না।

— দে নোভো

আমি উত্তরটি সম্পাদনা করে সংশোধন করেছি, যাতে লোকদের প্রথমে তাদের রেপো শাখা ভেঙে ফেলতে হবে না এবং তারপরে এসে মন্তব্যগুলি পড়তে হবে ... 🙄

— কামাফেদার ২

Answer 7

আরও একটি মামলা রয়েছে যেখানে git rebase --ontoবোঝা শক্ত: আপনি যখন প্রতিসাম্যগত পার্থক্য নির্বাচক (তিনটি বিন্দু ' ...') এর ফলে কোনও প্রতিশ্রুতিতে পুনরায় পঠন করেন when

গিট 2.24 (Q4 2019) সেই ক্ষেত্রে পরিচালনার জন্য আরও ভাল কাজ করে:

দেখুন কমিট 414d924 , 4effc5b কমিট , c0efb4c কমিট , 2b318aa কমিট (27 আগস্ট 2019), এবং 793ac7e কমিট , 359eceb কমিট (25 আগস্ট 2019) দ্বারা ডেন্টন লিউ ( Denton-L) ।
সাহায্যপ্রাপ্ত: এরিক সানশাইন ( sunshineco) , জুনিও সি হামানো ( gitster) , আভর আরনফজারি বার্জামসন ( avar) , এবং জোহানেস dschoশিন্ডেলিন ( ) ।
দেখুন কমিট 6330209 , c9efc21 কমিট (27 আগস্ট 2019), এবং 4336d36 কমিট দ্বারা (25 আগস্ট 2019) Ævar Arnfjörð Bjarmason ( avar)।
সাহায্যপ্রাপ্ত: এরিক সানশাইন ( sunshineco) , জুনিও সি হামানো ( gitster) , আভর আরনফজারি বার্জামসন ( avar) , এবং জোহানেস dschoশিন্ডেলিন ( ) ।
^{(দ্বারা একীভূত junio সি Hamano - gitster- মধ্যে কমিট 640f9cd , 30 সেপ্টেম্বর 2019)}

rebase: --ontoআরও ক্ষেত্রে দ্রুত এগিয়ে

আগে, যখন আমাদের নীচের গ্রাফ ছিল,

A---B---C (master)
     \
      D (side)

' git rebase --onto master... master side' দৌড়ানোর ফলে Dসর্বদা প্রত্যাবর্তন ঘটে , যাই হোক না কেন।

এই মুহুর্তে, "গিট ডিফ কমিট রেঞ্জের " ডাবল-ডট ' .."এবং ট্রিপল-ডট" ..."এর মধ্যে পার্থক্যগুলি কী? "

এখানে: " master..." বোঝায় master...HEAD, যা হ'ল B: হেড পার্শ্ব হেড (বর্তমানে চেক আউট): আপনি উপরে প্রত্যাবর্তন করছেন B।
কি রেবেস করছেন? কোন কমিট না মাস্টার, এবং থেকে পৌঁছানো sideশাখা: নেই শুধুমাত্র একটি ঝুলানো যে বিবরণ সমর্পণ D... যার উপরে আগে থেকেই B!

আবার, গিট ২.২৪-এর পূর্বে, এ জাতীয় rebase --ontoফলাফলের ফলে Dসর্বদা প্রত্যাবর্তন ঘটবে , তা যাই হোক না কেন।

তবে, পছন্দসই আচরণটি হ'ল পুনর্বাসনের বিষয়টি লক্ষ্য করা উচিত যে এটি দ্রুত এগিয়ে যায় এবং তার পরিবর্তে এটি করা উচিত।

এটি ওপি'র মতো rebase --onto B A, যা কিছুই করেনি।

এতে শনাক্তকরণ যুক্ত করুন can_fast_forwardযাতে এই কেসটি সনাক্ত করা যায় এবং একটি দ্রুত-অগ্রাহ্য করা হবে।
প্রথমত, গোটোস ব্যবহার করতে ফাংশনটি পুনরায় লিখুন যা যুক্তিটিকে সহজ করে।
পরবর্তী, যেহেতু

options.upstream &&
!oidcmp(&options.upstream->object.oid, &options.onto->object.oid)

শর্তগুলি এতে সরিয়ে ফেলা হয়েছিল cmd_rebase, আমরা একটি বিকল্প পুনরায় পেশ করি can_fast_forward।
বিশেষত, এর মার্জ ঘাঁটিগুলি পরীক্ষা করা upstreamএবং এর headমধ্যে একটি ব্যর্থ কেসটিকে ঠিক করে t3416।

T3416 এর সংক্ষিপ্ত গ্রাফটি নিম্নরূপ:

        F---G topic
       /
  A---B---C---D---E master

এবং ব্যর্থ কমান্ড ছিল

git rebase --onto master...topic F topic

এর আগে, গিত দেখতে পাবে যে এখানে একটি মার্জ বেস রয়েছে ( C, এর ফলাফল master...topic) এবং মার্জটি একই রকম ছিল যাতে এটি ভুলভাবে 1 ফিরে আসবে, ইঙ্গিত করে যে আমরা দ্রুত এগিয়ে যেতে পারি। এটি ABCFGপ্রত্যাশিত যখন ' ' তখন প্রত্যাবর্তিত গ্রাফটি ' ' হয়ে উঠবে ABCG।

একটি rebase --onto C F topicউপায়ে কোনো কমিট পরে F দ্বারা পৌঁছানো topicপ্রধান: যে Gশুধুমাত্র না Fনিজেই।
এই ক্ষেত্রে দ্রুত-ফরওয়ার্ডিং Fরিবেসড শাখায় অন্তর্ভুক্ত থাকবে , যা ভুল।

অতিরিক্ত যুক্তি দিয়ে আমরা সনাক্ত করতে পারি যে প্রবাহ এবং মাথাটির একত্রীকরণের ভিত্তি F। যেহেতু না করা হয় F, এর অর্থ হল যে আমরা কমিটস এর পুরো সেটটি ছাড়ছি না master..topic।
যেহেতু আমরা কিছু কমিটকে বাদ দিচ্ছি, তত দ্রুত ফরোয়ার্ড করা যায় না এবং তাই আমরা সঠিকভাবে 0 ফিরিয়ে দিই।

-fএই পরিবর্তনের ফলে ব্যর্থ হওয়া কেসগুলির পরীক্ষা করতে 'যুক্ত করুন' কারণ তারা দ্রুত এগিয়ে যাওয়ার প্রত্যাশা করে না যাতে একটি রিবেস বাধ্য করা হয়।