স্কোয়াশিং পুলের অনুরোধগুলি কি গিটের মার্জিং অ্যালগরিদমকে ভেঙে দেয়?


17

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

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

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

সুতরাং আমার প্রশ্নটি হল, এটির কাছাকাছি আসার কোনও উপায় আছে (অন্য কোনও বৈশিষ্ট্যের শাখাকে কখনই বন্ধ করে দেওয়া নয় যা আমার কর্মপ্রবাহকে সীমাবদ্ধ করে) বা স্কোয়াশ মার্জ করলে কি গিটের মার্জিং অ্যালগরিদমকে ভেঙে ফেলে?

উত্তর:


15

গিট সহ, কমিট করে

  • অপরিবর্তনীয়,
  • এবং একটি নির্দেশিত অ্যাসাইক্লিক গ্রাফ গঠন করুন।

স্কোয়াশিং কমিট একত্রিত করে না। পরিবর্তে, এটি একাধিক অন্যান্য কমিটের পরিবর্তনের সাথে একটি নতুন প্রতিশ্রুতি রেকর্ড করে। রিবেসিং একই রকম, তবে কমিটগুলি একত্রিত করে না। বিদ্যমান প্রতিশ্রুতি হিসাবে একই পরিবর্তনগুলির সাথে একটি নতুন প্রতিশ্রুতি রেকর্ডিংকে ইতিহাস পুনর্লিখন বলা হয় । তবে বিদ্যমান কমিটগুলি যেমন পরিবর্তনযোগ্য, তাই এটি "বিকল্প ইতিহাস লেখার" হিসাবে বোঝা উচিত।

একত্রিত হওয়ার ফলে দুটি পূর্বসূরীর ইতিহাস (শাখা) এর পরিবর্তনের সাথে এক সাধারণ পূর্বপুরুষের প্রতিশ্রুতিবদ্ধ পরিবর্তনগুলি একত্রিত করার চেষ্টা করা হয়।

সুতরাং আসুন আপনার ইতিহাস তাকান:

                                 F  feature2
                                /
               1---2---3---4---5    feature1 (old)
              /
-o---o---o---A---o---o---S          master

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

এই প্রতিবন্ধকতার কারণে, মার্জ / স্কোয়াশিংয়ের সাথে মোকাবিলা করার জন্য দুটি পন্থা রয়েছে:

  • হয় আপনি ইতিহাসের পুনর্লিখন ব্যবহার করেন, সেক্ষেত্রে আপনি একাধিক প্রতিশ্রুতি পাবেন যা একই পরিবর্তনের প্রতিনিধিত্ব করে। তারপর আপনি হবে রি-বেসের ফলে দ্বিতীয় বৈশিষ্ট্য শাখা সম্মুখের কমিট squashed:

                                     F  feature2 (old)
                                    /
                   1---2---3---4---5    feature1 (old)
                  /
    -o---o---o---A---o---o---S          master
                              \
                               F'       feature2
    
  • অথবা আপনি ইতিহাসের পুনর্লিখন ব্যবহার করেন না, সেক্ষেত্রে আপনি অতিরিক্ত মার্জ কমিটগুলি পেতে পারেন:

                                     F  feature2
                                    /
                   1---2---3---4---5    feature1 (old)
                  /                 \
    -o---o---o---A---o---o-----------M  master
    

    যখন বৈশিষ্ট্য 2 এবং মাস্টার একত্রীকরণ করা হয়, তখন সাধারণ পূর্বপুরুষ 5 টি প্রতিশ্রুতিবদ্ধ হয়।

উভয় ক্ষেত্রে আপনার কিছু সংহত করার প্রচেষ্টা হবে have উপরোক্ত দুটি কৌশল আপনি যেটি বেছে নিয়েছেন তার উপর এই প্রচেষ্টাটি খুব বেশি নির্ভর করে না। তবে তা নিশ্চিত করুন

  • শাখাগুলি স্বল্পস্থায়ী, তারা কতটা সীমাবদ্ধ হতে পারে সীমাবদ্ধ করার জন্য মাস্টার শাখা থেকে এবং এটি
  • আপনি নিয়মিতভাবে আপনার বৈশিষ্ট্য শাখায় মাস্টারকে মার্জ করেন, বা শাখাগুলি সিঙ্কে রাখার জন্য মাস্টারের বৈশিষ্ট্য শাখাটিকে পুনরায় ব্যবহার করুন।

একটি দলে কাজ করার সময়, বর্তমানে কোনটি নিয়ে কাজ করছেন তা সমন্বিত করা সহায়ক। এটি উন্নয়নের অধীনে বৈশিষ্ট্যগুলির সংখ্যা ছোট রাখতে সহায়তা করে এবং সংযুক্তির সংঘাতের সংখ্যা হ্রাস করতে পারে।


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

@ জিজ ঠিক এমনটিই ঘটে যখন আপনি কোনও পিআর স্কোয়াশ করেন। আমাকে সম্প্রতি একটি ওএসএস প্রকল্পে একটি পিআর ম্যানুয়ালি লিখতে হয়েছিল ( git cloneরেপো আইএন দিয়ে এবং আমার পরিবর্তিত ফাইলগুলি অনুলিপি করে!) কারণ আমি একটি শাখা থেকে ব্রাঞ্চ করেছি এবং তারপরে রক্ষণাবেক্ষণকারীটি প্রথম শাখা স্কোয়াশ করে। আমার চাকরিতে তারা স্কোয়াশ সংহতও করে। এর অর্থ আমি বৈশিষ্ট্যটি মার্জ হওয়া অবধি বৈশিষ্ট্যের bউপর নির্ভর করে এমন কোনও বৈশিষ্ট্যে কাজ করতে পারি না । aa
দূরে অ্যাকাউন্ট

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

1
@ জিজ মূল দৃশ্যে, হ্যাঁ আপনি বিবাদগুলি পেয়ে যাবেন যখন বৈশিষ্ট্য 2 কে মাস্টার হিসাবে মার্জ করা হবে কারণ 1–5 কমিটগুলি মার্জ করা এস-এ একই পরিবর্তনের সাথে বিরোধিত করবে সমাধানটি ফিচার 2 (সমাধান 1) পুনরায় শোধ করা বা স্কোয়াশিং / রিবিজিং ব্যবহার না করা all (সমাধান 2)
আমন

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

11

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

এ কারণেই এখানে আমাদের অলিখিত নিয়ম যতক্ষণ না আপনার বৈশিষ্ট্য শাখার উপর আর কেউ নির্ভর করে না, ততক্ষণ স্কোয়াশ করা ঠিক আছে, যা 90% সময়ের ক্ষেত্রে হতে পারে। অন্যথায়, একটি সরাসরি সংশ্লেষ প্রত্যেককে সমস্যা এড়াতে সহায়তা করে।


মাস্টার ইতিহাসে স্কোয়াশেড কমিট এবং একটি বৈশিষ্ট্য শাখা উভয়ই একটি পৃথক স্কোয়াশ-কেবল শাখা তৈরির জন্য এটি অক্ষত way ধরুন আপনার একটা feature-xyzশাখা আছে। আপনি একটি তৈরি করতে পারেন feature-xyz-squashedহিসাবে কমিট শাখা একই থেকে শুরু feature-xyzশাখা, git cherry-pickথেকে করে feature-xyzকরতে feature-xyz-squashed, তাদের সেখানে স্কোয়াশ, এবং একত্রীকরণ feature-xyz-squashedকরতে master। আপনার feature-xyzতখন মার্জ করা উচিত নয় । কখনও কখনও উপরেরটি অর্থবোধ করে (যেমন আপনি পাসওয়ার্ড ছিনতাইয়ের মাধ্যমে কমিটগুলি অন্তর্ভুক্ত করতে চান না), তবে এটি একটি কার্যকরী, খুব কমই অনুশীলন।
9:58
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.