Cherry-pick: এটি কী, কীভাবে সম্পাদন করতে হয় এবং Git কমান্ড

Git-এ cherry-pick কী

Cherry-pick হল git cherry-pick কমান্ড যা একটি বিদ্যমান কমিট থেকে পরিবর্তন নেয় এবং সেগুলিকে বর্তমান শাখায় একটি নতুন কমিট হিসাবে প্রয়োগ করে। মূল কমিটটি নিজের শাখায় তার জায়গায় থাকে, যখন লক্ষ্য শাখায় পরিবর্তনের একটি অনুলিপি তৈরি করা হয়। কমান্ডটি তখনই কার্যকর যখন আপনি সম্পূর্ণ শাখা স্থানান্তর না করে একটি নির্দিষ্ট সংশোধনী স্থানান্তর করতে চান।

বাক্য গঠন: git cherry-pick <commit-hash>। Git নির্দিষ্ট কমিটের তার প্যারেন্টের সাথে পার্থক্য (diff) বিশ্লেষণ করে এবং সেই পার্থক্যটি বর্তমান শাখায় প্রয়োগ করে। যদি একাধিক ফাইল পরিবর্তন করা হয়, তবে সেগুলি একসাথে স্থানান্তরিত হয়। কমান্ডটি রেঞ্জও গ্রহণ করে: git cherry-pick A..B — A থেকে B পর্যন্ত সব কমিট, A বাদে।

ফ্ল্যাগগুলি ক্ষমতা বাড়ায়: -n (--no-commit) কমিট তৈরি না করেই ওয়ার্কিং ডিরেক্টরি এবং ইনডেক্সে পরিবর্তন প্রয়োগ করে — যখন আপনি একাধিক কমিটের পরিবর্তনগুলিকে একটিতে একত্রিত করতে চান তখন কার্যকর। -x ফ্ল্যাগ কমিট বার্তায় একটি লাইন (cherry picked from commit ...) যোগ করে, যা ইতিহাসে পরিবর্তনের উৎপত্তি ট্র্যাক করা সহজ করে।

# হ্যাশ দ্বারা একটি একক কমিটে cherry-pick প্রয়োগ করুন
git cherry-pick a1b2c3d

# একাধিক কমিটে cherry-pick প্রয়োগ করুন (ক্রমান্বয়ে)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# অটো-কমিট ছাড়া cherry-pick প্রয়োগ করুন
git cherry-pick -n a1b2c3d

# -x ফ্ল্যাগ মূল কমিটের রেফারেন্স যোগ করে
git cherry-pick -x a1b2c3d

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

মূল পরিস্থিতি হল রিলিজ শাখাগুলির মধ্যে সংশোধনী স্থানান্তর। কল্পনা করুন: develop-এ একটি গুরুতর বাগ পাওয়া গেছে এবং ঠিক করা হয়েছে। রিলিজ শাখা release/v2.1 ইতিমধ্যে পৃথক হয়েছে এবং এতেও এই বাগটি রয়েছে। সম্পূর্ণ develop-কে release-এ merge করলে অনেক অসম্পূর্ণ কোড আসবে, অন্যদিকে একক ফিক্স কমিটে cherry-pick প্রয়োগ করা একটি নিরাপদ এবং সঠিক সমাধান।

দ্বিতীয় পরিস্থিতি হল পরবর্তী পুনরুদ্ধারের সাথে পরিবর্তনগুলি পূর্বাবস্থায় ফেরানো। যদি একটি কমিট git revert-এর মাধ্যমে পূর্বাবস্থায় ফেরানো হয় এবং পরে দেখা যায় যে পূর্বাবস্থায় ফেরানোটি ভুল ছিল — পূর্বাবস্থায় ফেরানো কমিটে cherry-pick প্রয়োগ করলে পরিবর্তনগুলি পুনরুদ্ধার হয়। এটি একটি revert পূর্বাবস্থায় ফেরানোর চেয়ে বেশি সঠিক কারণ এটি বারবার দ্বন্দ্ব সৃষ্টি করে না।

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

• বাগফিক্স — অসম্পূর্ণ কোড ছাড়া develop থেকে release-এ সংশোধনী স্থানান্তর।
• Hotfix — hotfix শাখা থেকে main এবং develop উভয়েই একসাথে সংশোধনী প্রয়োগ।
• ভুল revert পূর্বাবস্থায় ফেরানো — পরিবর্তন পুনরুদ্ধার করতে পূর্বাবস্থায় ফেরানো কমিটে cherry-pick প্রয়োগ।
• পরীক্ষা — ইন্টিগ্রেশন টেস্টিংয়ের জন্য বিভিন্ন শাখা থেকে নির্বাচিত কমিট সংগ্রহ।

Cherry-pick বনাম rebase এবং merge

Cherry-pick rebase এবং merge থেকে আলাদা কারণ এটি সম্পূর্ণ শাখার পরিবর্তে পৃথক কমিটের স্তরে কাজ করে। যেখানে rebase একটি শাখার সব কমিট স্থানান্তর করে এবং merge দুটি শাখাকে একত্রিত করে, cherry-pick শুধুমাত্র প্রয়োজনীয় কমিট নির্বাচন করে। এটি এটিকে আরও নির্ভুল টুল করে, কিন্তু আরও ম্যানুয়ালও।

আরেকটি পার্থক্য হল লেখকত্ব। Cherry-pick-এর সময়, Git ডিফল্টভাবে মূল কমিটের লেখক সংরক্ষণ করে, কিন্তু committer বর্তমান ব্যবহারকারী হয়ে যায়। কমিট বার্তা -x ফ্ল্যাগের মাধ্যমে উৎপত্তি ট্র্যাক করতে পারে। Rebase-এর সময়, লেখক এবং committer উভয়ই নতুন হ্যাশ সহ বর্তমান ব্যবহারকারী হয়ে যায়।

কর্মক্ষমতা: একটি একক কমিটে cherry-pick প্রয়োগ করা অনেক কমিট সহ দুটি শাখা merge করার চেয়ে দ্রুত। কিন্তু যদি আপনাকে ডজনখানেক কমিট স্থানান্তর করতে হয়, তবে একটি অস্থায়ী শাখা তৈরি করে rebase করা ভাল — এটি আরও কার্যকর হবে এবং ডজনখানেক হ্যাশ নির্দিষ্ট করার প্রয়োজন হবে না।

একাধিক কমিট স্থানান্তর

একাধিক কমিট একটি কমান্ড দিয়ে স্থানান্তর করা যেতে পারে: git cherry-pick A B C। Git নির্দিষ্ট ক্রমে কমিটগুলি ক্রমান্বয়ে প্রয়োগ করে। যদি কোনো কমিট দ্বন্দ্ব সৃষ্টি করে, cherry-pick থেমে যায়, এবং ডেভেলপারকে দ্বন্দ্ব সমাধান করতে হবে, তারপর git cherry-pick --continue দিয়ে চালিয়ে যেতে হবে।

কমিট রেঞ্জ: git cherry-pick A..B (A-এর পরে B পর্যন্ত সব কমিট, A বাদে) এবং git cherry-pick A^..B (A থেকে B পর্যন্ত সব কমিট)। রেঞ্জগুলি তখন সুবিধাজনক যখন আপনাকে প্যারেন্ট সম্পর্ক ছাড়া একটি শাখা থেকে সব কমিট স্থানান্তর করতে হয় — উদাহরণস্বরূপ, একটি পুরানো শাখা থেকে একটি নতুন শাখায় একটি সম্পূর্ণ ফিচার স্থানান্তর করার সময়।

--strategy ফ্ল্যাগ নির্ধারণ করে কিভাবে Git পরিবর্তন প্রয়োগ করবে। ডিফল্টরূপে recursive কৌশল ব্যবহার করা হয়, কিন্তু আপনি দ্বন্দ্বের পক্ষ স্বয়ংক্রিয়ভাবে বেছে নিতে ours বা theirs নির্দিষ্ট করতে পারেন। --mainline ফ্ল্যাগ merge কমিটে cherry-pick প্রয়োগ করার সময় ব্যবহার করা হয় — এটি প্যারেন্ট নম্বর (1 বা 2) নির্দিষ্ট করে যার সাপেক্ষে diff গণনা করা হয়।

# Cherry-pick কমিট রেঞ্জ
git cherry-pick develop~5..develop~2

# Merge কমিটে cherry-pick প্রয়োগ করুন (প্যারেন্ট নির্দিষ্ট করুন)
git cherry-pick -m 1 m9n0o1p

# theirs কৌশল ব্যবহার করুন
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# দ্বন্দ্ব সমাধানের পরে চালিয়ে যান
git cherry-pick --continue

Cherry-pick-এর সময় দ্বন্দ্ব

Cherry-pick-এর সময় দ্বন্দ্ব ঘটে যখন স্থানান্তরিত কমিটের পরিবর্তনগুলি একই লাইনগুলিকে প্রভাবিত করে যা লক্ষ্য শাখায় পরিবর্তন করা হয়েছিল। Git কার্যকর করা থামিয়ে দেয়, দ্বন্দ্বযুক্ত ফাইলগুলি চিহ্নিত করে এবং সমাধানের জন্য অপেক্ষা করে। অবস্থায়, এই ফাইলগুলি both modified হিসাবে দেখায়।

দ্বন্দ্ব সমাধানের পদক্ষেপ: দ্বন্দ্বযুক্ত ফাইল খুলুন, দ্বন্দ্ব চিহ্নিতকারী খুঁজুন (<<<<<<<, =======, >>>>>>>), বিষয়বস্তু সম্পাদনা করুন, চিহ্নিতকারীগুলি সরান, সমাধান করা ফাইলগুলির জন্য git add চালান, এবং git cherry-pick --continue নির্বাহ করুন। যদি দ্বন্দ্ব সমাধান করা না যায় — git cherry-pick --abort সম্পূর্ণ cherry-pick বাতিল করে, শাখাটিকে তার মূল অবস্থায় ফিরিয়ে দেয়।

একটি সাধারণ সমস্যা: কমিটটিতে ইতিমধ্যে বিদ্যমান পরিবর্তনের সমতুল্য পরিবর্তন রয়েছে। এই ক্ষেত্রে, Git cherry-pick চেষ্টা করার সময় “nothing to commit” বা “empty commit” রিপোর্ট করে। --keep-redundant-commits এবং --empty=keep ফ্ল্যাগগুলি Git-কে ক্রম বজায় রাখতে একটি খালি কমিট তৈরি করতে বাধ্য করে, যখন --skip এই ধরনের কমিট এড়িয়ে যাওয়ার অনুমতি দেয়।

# Cherry-pick-এর সময় দ্বন্দ্ব — থামুন
git cherry-pick a1b2c3d
# error: a1b2c3d... কমিট বার্তা প্রয়োগ করা যায়নি

# দ্বন্দ্ব সমাধান করুন → ইনডেক্সে যোগ করুন
git add src/conflicted_file.swift
git cherry-pick --continue

# খালি কমিট এড়িয়ে যান (ইতিমধ্যে প্রয়োগ করা হয়েছে)
git cherry-pick --skip

# সম্পূর্ণ বাতিল
git cherry-pick --abort

Cherry-pick-এর সেরা অনুশীলন

প্রথম নিয়ম: সর্বদা যাচাই করুন যে স্থানান্তরিত কমিটটি স্বয়ংসম্পূর্ণ। যদি কমিট A কমিট B-এর পরিবর্তনের উপর নির্ভর করে যা স্থানান্তরিত হচ্ছে না, তবে A-তে cherry-pick প্রয়োগ করলে বিল্ড ভেঙে যেতে পারে। Cherry-pick-এর আগে, git show --stat <hash>-এর মাধ্যমে কমিটটি কোন ফাইল পরিবর্তন করেছে তা পরীক্ষা করা কার্যকর।

দ্বিতীয় নিয়ম: cherry-pick অপারেশনগুলি ডকুমেন্ট করুন। -x ফ্ল্যাগ ব্যবহার করুন যাতে কমিট বার্তায় মূল কমিটের একটি রেফারেন্স থাকে। এটি পরবর্তী ইতিহাস বিশ্লেষণের সময় পরিবর্তনটি কোথা থেকে এসেছে তা বুঝতে সাহায্য করবে। -x ছাড়া, cherry-pick একটি সাধারণ কমিটের মতো দেখায় এবং এর উৎপত্তি শুধুমাত্র git log --graph-এর মাধ্যমে নির্ধারণ করা যায়।

তৃতীয় নিয়ম: যে শাখাগুলি খুব বেশি বিচ্যুত হয়েছে সেগুলির মধ্যে cherry-pick এড়িয়ে চলুন। যদি কমিট তৈরি হওয়ার পর অনেক সময় পেরিয়ে গেছে এবং কোডবেস উল্লেখযোগ্যভাবে পরিবর্তিত হয়েছে, তাহলে দ্বন্দ্ব অসংখ্য এবং জটিল হবে। এই ধরনের ক্ষেত্রে, লক্ষ্য শাখায় সংশোধনীটি পুনরায় বাস্তবায়ন করা ভাল — ডজনখানেক দ্বন্দ্ব সমাধানের চেয়ে কম সময় লাগবে।

• Cherry-pick শুধুমাত্র বাহ্যিক নির্ভরতা ছাড়া স্বয়ংসম্পূর্ণ কমিট।
• -x ফ্ল্যাগ বার্তায় কমিটের উৎপত্তি ডকুমেন্ট করার জন্য বাধ্যতামূলক।
• এড়িয়ে চলুন উল্লেখযোগ্য কোডবেস বিচ্যুতি সহ পুরানো কমিটে cherry-pick প্রয়োগ।
• CI/CD cherry-pick-এর পরে বিল্ড যাচাই করুন: দ্বন্দ্ব নাও ঘটতে পারে, কিন্তু কোড কম্পাইল নাও হতে পারে।
• PR মন্তব্য pull request তৈরি করার সময় নির্দেশ করুন কোন কমিটগুলি cherry-pick-এর মাধ্যমে স্থানান্তরিত হয়েছে।