Cherry-pick — এটি কী, প্রক্রিয়া এবং Git-এ প্রয়োগ

Cherry-pick কী?

Cherry-pick হল একটি Git কমান্ড যা একটি নির্দিষ্ট কমিট থেকে পরিবর্তনগুলি কপি করে এবং বর্তমান ব্রাঞ্চে একটি নতুন কমিট হিসেবে প্রয়োগ করে। নামটি “চেরি বাছাই”-এর রূপক থেকে এসেছে: ডেভেলপার শুধুমাত্র প্রয়োজনীয় কমিটগুলি নির্বাচন করে, বাকিগুলি উপেক্ষা করে।

Merge-এর থেকে ভিন্ন, cherry-pick মার্জ কমিট তৈরি করে না এবং ব্রাঞ্চগুলির সম্পূর্ণ মার্জের প্রয়োজন হয় না। Rebase-এর থেকে ভিন্ন, cherry-pick কমিটের ক্রম স্থানান্তর করে না — শুধুমাত্র নির্দিষ্ট কমিটগুলি। এটি cherry-pick-কে ফিক্সের নির্দিষ্ট স্থানান্তরের জন্য একটি আদর্শ টুল করে তোলে।

Atlassian, 2025 অনুসারে, cherry-pick 47% টিম দ্বারা ব্যবহৃত হয় যারা একসাথে একাধিক রিলিজ ব্রাঞ্চ নিয়ে কাজ করে। Cherry-pick বিশেষত মোবাইল ডেভেলপমেন্টে চাহিদাযুক্ত, যেখানে একসাথে অ্যাপ্লিকেশনের একাধিক সংস্করণ (LTS রিলিজ) সমর্থিত হয় এবং তাদের মধ্যে ফিক্স স্থানান্তরের প্রয়োজন হয়।

স্থানান্তর প্রক্রিয়া

Cherry-pick সম্পাদন করার সময়, Git নির্দিষ্ট কমিট এবং তার প্যারেন্টের মধ্যে diff গণনা করে, তারপর এই diff বর্তমান ব্রাঞ্চে প্রয়োগ করে। যদি পরিবর্তনগুলি দ্বন্দ্ব ছাড়া প্রয়োগ হয় — Git একই বার্তা কিন্তু নতুন SHA সহ একটি নতুন কমিট তৈরি করে। যদি দ্বন্দ্ব থাকে — cherry-pick ম্যানুয়াল সমাধানের জন্য থামে।

Cherry-pick কীভাবে কাজ করে

সিনট্যাক্স cherry-pick সহজ: স্থানান্তরের জন্য কমিটের হ্যাশ নির্দিষ্ট করুন। Git পরিবর্তনগুলি বর্তমান ব্রাঞ্চে একটি নতুন কমিট হিসেবে কপি করে। একসাথে একাধিক কমিট এবং সম্পূর্ণ রেঞ্জের স্থানান্তর সমর্থিত।

# বর্তমান ব্রাঞ্চে একটি কমিট স্থানান্তর করুন
git cherry-pick a1b2c3d4

# একাধিক কমিট স্থানান্তর করুন
git cherry-pick a1b2c3d4 e5f6g7h8

# কমিটের রেঞ্জ স্থানান্তর করুন (a1b2 থেকে f9e8 পর্যন্ত, a1b2 বাদে)
git cherry-pick a1b2c3d4..f9e8d7c6

Cherry-pick সম্পাদনের পর, বর্তমান ব্রাঞ্চ উৎস থেকে পরিবর্তনসহ একটি নতুন কমিট পায়। কমিট বার্তা ডিফল্টভাবে উৎস থেকে কপি করা হয়, কিন্তু -n ফ্ল্যাগ (কমিট না তৈরি) বা --edit (বার্তা সম্পাদনা) দিয়ে পরিবর্তন করা যেতে পারে।

ফিক্স স্থানান্তরের উদাহরণ

একটি সাধারণ পরিস্থিতি বিবেচনা করুন: develop-এ একটি গুরুত্বপূর্ণ বাগ পাওয়া এবং ঠিক করা হয়েছে, যা রিলিজ ব্রাঞ্চ release/v2.0-তেও বিদ্যমান। পুরো develop কে রিলিজ ব্রাঞ্চে মার্জ না করে শুধুমাত্র এই ফিক্স স্থানান্তর করা প্রয়োজন।

# Develop-এ ফিক্সসহ কমিট হ্যাশ খুঁজুন
git log --oneline develop
# a1b2c3d fix: null check in payment processing

# রিলিজ ব্রাঞ্চে স্যুইচ করুন
git checkout release/v2.0

# ফিক্স প্রয়োগ করুন
git cherry-pick a1b2c3d4

# যদি দ্বন্দ্ব থাকে — সমাধান করুন এবং চালিয়ে যান
git add src/payment/PaymentProcessor.kt
git cherry-pick --continue

-x ফ্ল্যাগ কমিট বার্তায় মূল SHA-এর একটি রেফারেন্স যোগ করে: “(cherry picked from commit a1b2c3d4)”। এটি ট্র্যাক করা সহজ করে যে কমিট কোথা থেকে স্থানান্তরিত হয়েছে। অস্থায়ী খসড়া ছাড়া সব পরিস্থিতিতে -x ব্যবহার করার সুপারিশ করা হয়।

দ্বন্দ্ব নিয়ে কাজ করা

দ্বন্দ্বের ক্ষেত্রে, cherry-pick merge-এর মতো আচরণ করে: Git থামে এবং দ্বন্দ্বপূর্ণ ফাইলগুলি চিহ্নিত করে। ডেভেলপার দ্বন্দ্ব সমাধান করে, git add চালায় এবং git cherry-pick --continue সম্পাদন করে। বাতিল করতে — git cherry-pick --abort। --strategy ফ্ল্যাগ মার্জ কৌশল নির্দিষ্ট করার অনুমতি দেয় (যেমন, বিকল্পসহ recursive)।

# Cherry-pick-এর সময় দ্বন্দ্ব সমাধান
# Git দ্বন্দ্বপূর্ণ ফাইল দেখায়
git status

# ম্যানুয়ালি সমাধান করুন, তারপর:
git add অনুমোদিত_ফাইল.kt
git cherry-pick --continue

# অথবা cherry-pick বাতিল করুন:
git cherry-pick --abort

কখন Cherry-pick ব্যবহার করবেন

Cherry-pick সেই পরিস্থিতিতে সর্বোত্তম যেখানে সম্পূর্ণ ব্রাঞ্চ মার্জ না করে পরিবর্তনের নির্দিষ্ট স্থানান্তর প্রয়োজন। আসুন পাঁচটি প্রধান ক্ষেত্রে দেখি যেখানে cherry-pick সেরা পছন্দ হয়ে ওঠে।

• Hotfix স্থানান্তর — develop-এ একটি ফিক্স পাওয়া গেছে, কিন্তু এটি রিলিজ ব্রাঞ্চে (release/v2.0) প্রয়োগ করা প্রয়োজন। Cherry-pick develop-এর অসমাপ্ত বৈশিষ্ট্যগুলিকে প্রভাবিত না করে শুধুমাত্র ফিক্স কমিট স্থানান্তর করে
• পুরানো সংস্করণে ব্যাকপোর্ট — বর্তমান সংস্করণের জন্য একটি ফিক্স LTS রিলিজে স্থানান্তর করা প্রয়োজন। পুরো বর্তমান কোডবেস মার্জ করার পরিবর্তে, cherry-pick শুধুমাত্র প্রয়োজনীয় কমিট নির্বাচন করে
• ভুল ব্রাঞ্চে কমিট পূর্বাবস্থায় ফেরানো — যদি একটি কমিট ভুল ব্রাঞ্চে করা হয়, cherry-pick এটি সঠিক ব্রাঞ্চে স্থানান্তর করে, এবং মূল কমিট বাতিল করা হয়
• ডকুমেন্টেশন স্থানান্তর — README বা কনফিগারেশন ফাইলের পরিবর্তন যা সব ব্রাঞ্চে থাকা উচিত, cherry-pick-এর মাধ্যমে স্থানান্তর করা সুবিধাজনক
• নির্বাচনী প্রয়োগ — প্রোটোটাইপ ব্রাঞ্চ থেকে, পুরো প্রোটোটাইপ মূল ডেভেলপমেন্টে স্থানান্তর না করে শুধুমাত্র একটি সফল কমিট নেওয়া প্রয়োজন

মোবাইল ডেভেলপমেন্টের জন্য, অ্যাপ্লিকেশনের একাধিক সংস্করণ সমর্থন করার সময় cherry-pick গুরুত্বপূর্ণভাবে প্রয়োজনীয়। উদাহরণস্বরূপ, যদি Google Play-তে ইতিমধ্যে প্রকাশিত সংস্করণ 3.2-এ একটি বাগ পাওয়া যায়, এবং develop-এ সংস্করণ 4.0-এর জন্য কোড থাকে — cherry-pick সব ব্রেকিং চেঞ্জ মার্জ না করে v3.x ব্রাঞ্চে ফিক্স স্থানান্তরের অনুমতি দেয়। এটি বিশেষত সেই প্রকল্পগুলির জন্য প্রাসঙ্গিক যেখানে বিভিন্ন API এবং নির্ভরতা সহ একসাথে দুই বা ততোধিক প্রধান সংস্করণ সমর্থিত হয়।

ব্যবহারিক উদাহরণ: একটি মোবাইল অ্যাপ্লিকেশনে Android 12-এ Google Sign-In-এর মাধ্যমে প্রমাণীকরণের সময় ক্র্যাশ পাওয়া গেছে। ফিক্স develop-এ করা হয়েছে এবং কোড রিভিউ পাস করে। তবে, বর্তমান রিলিজ ব্রাঞ্চ v2.5 ইতিমধ্যে বিটা পরীক্ষার পর্যায়ে রয়েছে। Develop থেকে release/v2.5-এ ফিক্স কমিটের Cherry-pick আসন্ন রিলিজে ফিক্স অন্তর্ভুক্ত করার অনুমতি দেয়, অন্যান্য পরিবর্তনগুলি স্থানান্তর না করে যা এখনও প্রকাশের জন্য প্রস্তুত নয়।

মোবাইল প্রকল্পে cherry-pick ব্যবহার করার সময়, নির্ভরতা বিবেচনা করা গুরুত্বপূর্ণ: যদি ফিক্স ফাইলগুলিকে প্রভাবিত করে যা রিলিজ ব্রাঞ্চের বিচ্ছেদ বিন্দুর পরে develop-এ পরিবর্তন করা হয়েছিল, তাহলে cherry-pick পরিবর্তনের অসম্পূর্ণ সেট আনতে পারে। এই ধরনের ক্ষেত্রে, যাচাই করা প্রয়োজন যে সমস্ত সম্পর্কিত পরিবর্তনও স্থানান্তরিত হয়েছে, অন্যথায় অ্যাপ্লিকেশন বিল্ড নাও হতে পারে বা ভুলভাবে কাজ করতে পারে। শেয়ার্ড ব্রাঞ্চে পরিবর্তন পুশ করার আগে সর্বদা cherry-pick-এর পরে বিল্ড পরীক্ষা করুন।

Cherry-pick বনাম Merge বনাম Rebase

Git-এ পরিবর্তন সংহত করার তিনটি মূল টুল — merge, rebase এবং cherry-pick — বিভিন্ন কাজ সমাধান করে। পছন্দ নির্ভর করে কতটুকু পরিবর্তন স্থানান্তর করতে হবে এবং ইতিহাস কেমন হওয়া উচিত তার উপর।

Merge — যখন আপনাকে দুটি ব্রাঞ্চ সম্পূর্ণরূপে মার্জ করতে এবং শাখাকরণ তথ্য সংরক্ষণ করতে হবে। Rebase — যখন আপনাকে পরিষ্কার ইতিহাসসহ ব্যক্তিগত ব্রাঞ্চ সর্বশেষ অবস্থায় আপডেট করতে হবে। Cherry-pick — যখন আপনার শুধুমাত্র একটি কমিট বা কয়েকটি নির্বাচিত কমিট প্রয়োজন।

অনুশীলনে, এই টুলগুলি সংযুক্ত হয়: একটি ফিচার develop-এ পর্যায়ক্রমিক rebase-এর সাথে বিকশিত হয়, তারপর --no-ff merge-এর মাধ্যমে মার্জ করা হয়, এবং যখন অন্য ব্রাঞ্চে ফিক্স স্থানান্তরের প্রয়োজন হয়, cherry-pick ব্যবহার করা হয়। প্রতিটি টুল তার নিজস্ব পর্যায়ে নিজস্ব কাজ সমাধান করে।

Cherry-pick-এর ঝুঁকি এবং সীমাবদ্ধতা

Cherry-pick একটি উপযোগী কিন্তু সম্ভাব্য বিপজ্জনক টুল যখন ভুলভাবে বা অতিরিক্ত ব্যবহার করা হয়। প্রধান ঝুঁকিগুলি কমিট ডুপ্লিকেশন, প্রসঙ্গ হারানো এবং পরবর্তী মার্জের সময় দ্বন্দ্বের সাথে সম্পর্কিত।

• কমিট ডুপ্লিকেশন — যদি একই কমিট পরে merge-এর মাধ্যমে ব্রাঞ্চে আসে, Git পরিবর্তনে অভিন্ন দ্বিতীয় কমিট তৈরি করবে। এটি ইতিহাস দূষিত করে এবং git bisect জটিল করে তোলে
• প্রসঙ্গ হারানো — cherry-pick diff স্থানান্তর করে কিন্তু প্যারেন্ট কমিট এবং নির্ভরতা সম্পর্কে তথ্য স্থানান্তর করে না। যদি cherry-pick কমিট B ছাড়া কমিট A প্রয়োগ করে যার উপর A নির্ভরশীল ছিল, যৌক্তিক ত্রুটি ঘটতে পারে
• মার্জ দ্বন্দ্ব — cherry-pick-এর পর, সম্পূর্ণ ব্রাঞ্চ মার্জের সময়, Git একই পরিবর্তন দুবার দেখতে পারে এবং এমন দ্বন্দ্ব তৈরি করতে পারে যা সাধারণ মার্জে এড়ানো যেত
• ট্রেসেবিলিটির অভাব -x ফ্ল্যাগ ছাড়া, জানা অসম্ভব যে একটি কমিট অন্য ব্রাঞ্চ থেকে স্থানান্তরিত হয়েছিল। পরিবর্তনের উৎপত্তি খুঁজতে গিয়ে, একজন ডেভেলপার কমিটের উৎস নির্ণয়ে ঘন্টা ব্যয় করতে পারে

ঝুঁকি কমানোর সুপারিশ: মূল SHA নির্দেশ করতে সর্বদা -x ফ্ল্যাগ ব্যবহার করুন, কমিট বার্তায় cherry-pick-এর কারণ ডকুমেন্ট করুন, এবং যখন সম্ভব merge ব্যবহার করুন যখন প্রসঙ্গ অনুমতি দেয়। যদি cherry-pick বেশি হয়ে যায় — ব্রাঞ্চ পুনর্গঠন বিবেচনা করুন।

Cherry-pick-এর জন্য স্বয়ংক্রিয় পরীক্ষা

CI পাইপলাইনগুলি cherry-pick-কে একটি পৃথক পরিস্থিতি হিসেবে বিবেচনা করা উচিত। একটি স্বয়ংক্রিয় পরীক্ষা সেটআপ করার সুপারিশ করা হয়: যখন একটি cherry-pick কমিট তৈরি হয়, CI যাচাই করে যে পরিবর্তিত ফাইলগুলি প্রত্যাশিত সেটের সাথে মেলে এবং প্রভাবিত মডিউলের জন্য পরীক্ষা চালায়। এটি ব্রাঞ্চগুলির মধ্যে পরিবর্তন স্থানান্তর করার সময় রিগ্রেশনের ঝুঁকি হ্রাস করে।