গিট চেরি-পিক বনাম মার্জ ওয়ার্কফ্লো


302

ধরে নিই যে আমি কোনও রেপো রক্ষণাবেক্ষণকারী এবং আমি কোনও অবদানকারীর কাছ থেকে পরিবর্তন আনতে চাই, সেখানে কয়েকটি সম্ভাব্য ওয়ার্কফ্লো রয়েছে:

  1. আমি cherry-pickপ্রত্যেকে প্রত্যন্ত থেকে (ক্রম) প্রতিশ্রুতিবদ্ধ। এই ক্ষেত্রে গিট রিমোট শাখার সাথে সম্পর্কিত নয় বলে প্রতিশ্রুতি রেকর্ড করে।
  2. আমি mergeশাখা, সমস্ত পরিবর্তন আনছি এবং একটি নতুন "সংঘাত" প্রতিশ্রুতি যুক্ত করুন (যদি প্রয়োজন হয়)।
  3. আমি mergeপ্রত্যেকে প্রত্যন্ত শাখা থেকে পৃথক পৃথকভাবে (আবার ক্রমে) প্রতিশ্রুতিবদ্ধ করি, যার ফলে প্রতিটি কমিটকে এক হিসাবে গোষ্ঠীভুক্ত না করে প্রতিটি কমিটের জন্য দ্বন্দ্ব রেকর্ড করা যায়।
  4. সম্পূর্ণতার জন্য, আপনি একটি করতে পারেন rebase( cherry-pickবিকল্প হিসাবে একই ?) তবে আমার বোধগম্যতা এটি অবদানকারীদের জন্য বিভ্রান্তি সৃষ্টি করতে পারে। হতে পারে এটি বিকল্প 1 সরিয়ে দেয়।

2 এবং 3 উভয় ক্ষেত্রেই গিট কমিটের শাখার ইতিহাস 1 এর বিপরীতে রেকর্ড করে।

বর্ণিত পদ্ধতি cherry-pickবা mergeবর্ণিত ব্যবহারের মধ্যে প্রো এবং কনসের কী কী ? আমার বোধগম্যতা হল যে পদ্ধতি 2টি আদর্শ, তবে আমি অনুভব করি যে একটি বৃহত্তর অঙ্গীকারকে একক "দ্বন্দ্ব" সংশ্লেষের সাথে সমাধান করা, সবচেয়ে পরিষ্কার সমাধান নয়।

উত্তর:


296

উভয় rebase(এবং cherry-pick) এবং mergeতাদের সুবিধা এবং অসুবিধা রয়েছে। আমি mergeএখানে তর্ক করছি , তবে এটি উভয়ই বোঝার পক্ষে। ( যেখানে পছন্দের ক্ষেত্রে একটি বিকল্প, সু-বিতর্কিত উত্তরের জন্য এখানে দেখুন rebase))

mergeওভার পছন্দ করা হয় cherry-pickএবং rebaseকারণের একটি দম্পতি জন্য।

  1. দৃust়তা । একটি এর SHA1 এ আইডেন্টিফায়ার এটা শুধু এবং তার মধ্যে কিন্তু শনাক্ত কমিট সম্পর্কিত সব অন্যান্য করে এটি বসে। এটি আপনাকে একটি গ্যারান্টি দেয় যে প্রদত্ত SHA1 এ সংগ্রহস্থলের অবস্থা সমস্ত ক্লোন জুড়ে অভিন্ন। (তত্ত্বগতভাবে) এমন কোনও সম্ভাবনা নেই যে কেউ একই রকম পরিবর্তনের মতো দেখায় কিন্তু বাস্তবে আপনার ভান্ডারটিকে দূষিত বা হাইজ্যাক করছে। আপনি স্বতন্ত্র পরিবর্তনগুলি চেরি-বাছাই করতে পারেন এবং সেগুলি সম্ভবত একই রকম হয় তবে আপনার কোনও গ্যারান্টি নেই। (একটি গৌণ মাধ্যমিক ইস্যু হিসাবে নতুন চেরি-বাছাই করা কমিটি যদি একই প্রতিশ্রুতিতে আবারো চেরি-বাছাই করে তবে অতিরিক্ত স্থান গ্রহণ করবে, কারণ আপনার কাজের অনুলিপিগুলি অভিন্ন হওয়ার পরেও তারা উভয়েই ইতিহাসে উপস্থিত থাকবে।)
  2. ব্যবহারের সহজতা । লোকেরা mergeকর্মফলকে মোটামুটি সহজেই বোঝার ঝোঁক নেয় । rebaseআরও উন্নত হিসাবে বিবেচিত হয়। উভয়ই বোঝা ভাল, তবে যে লোকেরা সংস্করণ নিয়ন্ত্রণে বিশেষজ্ঞ হতে চান না (যা আমার অভিজ্ঞতায় অনেক সহকর্মী অন্তর্ভুক্ত করেছেন যারা তাদের কাজগুলিতে ভাল, তবে অতিরিক্ত সময় ব্যয় করতে চান না) তাদের আরও সহজ হতে পারে সময় শুধু মার্জ করা।

এমনকি একীভূত ভারী কর্মপ্রবাহ সহ rebaseএবং cherry-pickএখনও বিশেষ ক্ষেত্রে কার্যকর useful

  1. এর এক নেতিবাচক ঘটনা mergeহ'ল বিশৃঙ্খল ইতিহাস। rebaseআপনার ইতিহাসে ছড়িয়ে ছিটিয়ে থাকা থেকে দীর্ঘমেয়াদি প্রতিশ্রুতিগুলি রোধ করে, যেমন আপনি যদি পর্যায়ক্রমে অন্যের পরিবর্তনে একীভূত হন। আমি এটি ব্যবহার করার সাথে সাথে এটিই এর মূল উদ্দেশ্য। তুমি কী হতে চাও খুব সাবধানতা অবলম্বনrebase কোনও কোডই নয় যা আপনি অন্যান্য ভান্ডারগুলির সাথে ভাগ করেছেন। একবার কোন প্রতিশ্রুতি সম্পাদন করা হলে এর pushউপরে অন্য কেউ প্রতিশ্রুতিবদ্ধ হতে পারে এবং রিবাইজিংয়ের ফলে উপরে বর্ণিত নকলকরণটি সর্বোত্তম কারণ হয়ে উঠবে। সবচেয়ে খারাপ আপনি খুব বিভ্রান্ত ভাণ্ডার এবং সূক্ষ্ম ত্রুটিগুলি দিয়ে শেষ করতে পারেন এটি আপনাকে বের করতে খুব বেশি সময় লাগবে।
  2. cherry-pick আপনি মূলত বাতিল করার সিদ্ধান্ত নিয়েছেন এমন একটি বিষয় শাখা থেকে পরিবর্তনগুলির একটি ছোট উপসেট স্যাম্পল করার জন্য দরকারী, তবে বুঝতে পেরেছেন যে এখানে কয়েকটি কার্যকর টুকরা রয়েছে।

একাধিক পরিবর্তন একত্রিত করা পছন্দ করে: এটি কেবল অনেক সহজ a আপনি একবারে প্রচুর পরিমাণে খালি শুরু করার পরে স্বতন্ত্র চেঞ্জসেটগুলির মার্জ করতে খুব ক্লান্তি লাগতে পারে। গিটে মার্জ রেজোলিউশন (এবং মার্চুরিয়ালে এবং বাজারে) খুব ভাল। আপনি বেশিরভাগ সময় লম্বা শাখাগুলি মার্জ করে বড় সমস্যাগুলির মধ্যে চলে যাবেন না। আমি সাধারণত সমস্ত কিছু একসাথে একত্রীকরণ করি এবং 9000 এর চেয়ে কম সংঘাতের থেকে কম। এটি এখনও অনেক কাজ ছিল, তবে একবারে এটি করার জন্য যতটা চেষ্টা করা হয়েছে ততটা নয়। যদি আমি প্রচুর সংঘাতের থাকি তবে আমি মার্জ টুকরোয়ালটি ব্যাক আপ করে আবার চালনা করব। তারপরেও আমি বড় অংশগুলিতে এটি করি। খুব বাস্তব উদাহরণ হিসাবে আমার এক সহকর্মী ছিল যার একত্রীকরণের জন্য 3 মাসের মূল্যের পরিবর্তন ছিল এবং 250000 লাইন কোড-বেসে 9000 সংঘাত পেয়েছিল। আমরা কি ফিক্স করেছেন একটি সময়ে একত্রীকরণ এক মাস এর মূল্য কি হল: দ্বন্দ্ব সুসংগত গড়তে না এবং টুকরা ফলাফলে এরকম পর্যন্ত


1
প্রকৃতপক্ষে, তত্ত্বে এমন একটি সম্ভাবনা রয়েছে যে ম্যালরি একই SHA1 কিন্তু বিভিন্ন সামগ্রী নিয়ে কমিট তৈরি করে আপনার ভাণ্ডারকে দূষিত করতে পারে, সম্ভবত এটি বাস্তবে কখনও ঘটবে না। :)
বোম্বে

1
হা :) আমি বলতে চাইছি "তত্ত্বের মধ্যে মতবিরোধগুলি এত কম যে আপনি এটির উপর নির্ভর করতে পারবেন না", তবে আপনি ঠিক বলেছেন যে এটি টপসি-টারভি পড়েছে।
কোয়ার্ক

"মার্জ - স্কোয়াশ" সম্পর্কে আপনি কী ভাবেন?
সেমিসিগিন্টি

@ বোম্বে যদি ম্যালোরি সফল হতে চান তবে তাকে বিশেষভাবে একই SHA1 দিয়ে মূল প্রতিশ্রুতিবদ্ধ এবং দ্বিতীয় প্রতিশ্রুতি তৈরি করতে হবে। সুতরাং অন্য একটি প্রশ্ন হতে পারে: দু'জনের (কিছুটা) বগাস উপস্থিত হওয়ার বিষয়ে কী কী প্রতিক্রিয়া রয়েছে এবং আপনি লক্ষ্য করছেন না? ;)
জোও পোর্তেলা

64
9000 দ্বন্দ্ব? আমি আমার চাকরি ছেড়ে মৌমাছি রক্ষক হয়ে উঠতাম
সেবাস্তিয়ান প্যাটেন

95

আমার মতে চেরি-বাছাই করা বিরল পরিস্থিতিতে যেখানে এটি প্রয়োজন সেখানে সংরক্ষণ করা উচিত, উদাহরণস্বরূপ যদি আপনি সরাসরি 'মাস্টার' শাখায় (ট্রাঙ্ক, মূল উন্নয়ন শাখা) কিছুটা ঠিক করেন এবং বুঝতে পেরেছেন যে এটি 'রক্ষণাবেক্ষণের ক্ষেত্রেও প্রয়োগ করা উচিত '। আপনার একত্রিত হয়ে, বা পুনর্বাসনে (বা "গিট টান --rebase") এর ভিত্তিতে ওয়ার্কফ্লো ভিত্তিক করা উচিত।

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

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

আছে HTH।


19
+1 পয়েন্টটির জন্য যে রিবেস / চেরি-বাছাই করা প্রকৃতপক্ষে "অনুলিপি" করে এবং তাই মূল প্রতিশ্রুতিটির লিঙ্কটি হারাতে চায়।
স্টাডিজিক

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

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

4
@ জাকুব দুটি কমান্ড যা একটি বাগফিক্স শাখা তৈরি এবং মার্জ করার জন্য অপরিহার্য: git blameবাগটি প্রবর্তনকারী প্রতিশ্রুতি সন্ধান করতে এবং git branch --containsকোথায় শাখাটি মার্জ করতে হবে তা নির্ধারণ করতে। এই পোস্টে
gcbenison

-10

রিবেস এবং চেরি-পিক হ'ল একমাত্র উপায় আপনি পরিষ্কার প্রতিশ্রুতিবদ্ধ ইতিহাস রাখতে পারেন। মার্জ ব্যবহার করা এবং মার্জ সংঘাত তৈরি থেকে বিরত থাকুন। আপনি যদি জারিট সেট করে একটি প্রকল্পটি প্রয়োজনে মার্জ করতে এবং একটি প্রকল্প চেরি-পিক মোডে ব্যবহার করে নিজের চেষ্টা করে চলেছেন।


এটি কীভাবে প্রশ্নের উত্তর দেয় তা মোটেও পরিষ্কার নয়, সম্ভবত কিছু উদাহরণ কিছু আলোকপাত করবে।
অ্যাড্রিয়ান ন্যাসুই

1
আপনার ইতিহাসটি সোজা দেখবে এ বিষয়টি বোঝা সহজ নয় যে বোঝায় না।
নিকোলিমো 86

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

এই লোকটি এখনই একটি পদকের দাবিদার। তিনি জানে যে তিনি নিচে ভোটগ্রহণ চালিয়ে যাবেন তবে এটি সঠিক উত্তর। যশ।
পিডব্লিউ কাদ

দুঃখিত, আমি এই মন্তব্যগুলি এখনও অবধি দেখতে পাইনি, দয়া করে শেষ করার আগে আপনার পরীক্ষার পরিবেশে এটি ব্যবহার করে দেখুন এবং আপনার জন্য কী কাজ করে তা করুন! আমার প্রায় 600 বিকাশকারী একাধিক পণ্য শাখায় অবদান রাখে, আমি স্থানীয় কর্মক্ষেত্রে ডেভেলপাররা কী করে তা আমি বিবেচনা করি না, যখন সংহতকরণের জন্য কোনও পরিবর্তন জমা দেওয়া হয় তখন এটি চেরি-পিক বিকাশ করতে সক্ষম হতে হবে বা কখনও কখনও মুক্তি বা বাগ ফিক্স শাখা হতে পারে। এফওয়াইআই ... আমি জেরিট ব্যবহার করি।
নাগরাজ মাগাদুম
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.