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 کیسے کام کرتا ہے

نحو سادہ ہے: منتقل کرنے کے لیے کمٹ کا ہیش بتائیں۔ 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 allowed_file.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 برانچ میں اصلاح منتقل کرنے کی اجازت دیتا ہے۔ یہ خاص طور پر ان منصوبوں کے لیے متعلقہ ہے جہاں مختلف APIs اور انحصار کے ساتھ دو یا زیادہ اہم ورژن ایک ساتھ برقرار رکھے جاتے ہیں۔

عملی مثال: ایک موبائل ایپلیکیشن میں Android 12 پر Google Sign-In کے ذریعے تصدیق کے دوران کریش پایا گیا۔ اصلاح develop میں کی گئی اور کوڈ کا جائزہ پاس کرتی ہے۔ تاہم، موجودہ ریلیز برانچ v2.5 پہلے ہی بیٹا ٹیسٹنگ کے مرحلے میں ہے۔ Develop سے release/v2.5 میں اصلاح کمٹ کا Cherry-pick آنے والی ریلیز میں اصلاح شامل کرنے کی اجازت دیتا ہے، بغیر ان دیگر تبدیلیوں کو منتقل کیے جو ابھی تک ریلیز کے لیے تیار نہیں ہیں۔

موبائل منصوبوں میں cherry-pick استعمال کرتے وقت، انحصار پر غور کرنا ضروری ہے: اگر اصلاح ان فائلوں کو متاثر کرتی ہے جو ریلیز برانچ کے انحراف کے مقام کے بعد develop میں تبدیل کی گئی تھیں، تو cherry-pick تبدیلیوں کا نامکمل سیٹ لا سکتا ہے۔ ایسی صورتوں میں، یہ تصدیق کرنا ضروری ہے کہ تمام متعلقہ تبدیلیاں بھی منتقل کی گئی ہیں، ورنہ ایپلیکیشن بن نہیں سکتی یا غلط طریقے سے کام کر سکتی ہے۔ مشترکہ برانچ میں تبدیلیاں push کرنے سے پہلے ہمیشہ 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 ایک ہی تبدیلیوں کو دو بار دیکھ سکتا ہے اور ایسے تنازعات پیدا کر سکتا ہے جو عام merge سے بچے جا سکتے تھے
• ٹریس ایبلٹی کا فقدان -x فلیگ کے بغیر، یہ جاننا ناممکن ہے کہ کمٹ کسی اور برانچ سے منتقل کیا گیا تھا۔ تبدیلی کی اصلیت تلاش کرتے ہوئے، ایک ڈویلپر کمٹ کی اصلیت معلوم کرنے میں گھنٹے گزار سکتا ہے

خطرات کو کم کرنے کی سفارشات: اصل SHA بتانے کے لیے ہمیشہ -x فلیگ استعمال کریں، کمٹ پیغام میں cherry-pick کی وجہ دستاویز کریں، اور جب ممکن ہو تو cherry-pick کے بجائے merge استعمال کریں جب سیاق و سباق اجازت دے۔ اگر cherry-pick بہت زیادہ ہو جائیں — برانچوں کی تنظیم نو پر غور کریں۔

Cherry-pick کے لیے خودکار جانچ

CI پائپ لائنز کو cherry-pick کو ایک علیحدہ منظرنامہ سمجھنا چاہیے۔ ایک خودکار جانچ قائم کرنے کی سفارش کی جاتی ہے: جب cherry-pick کمٹ بنایا جاتا ہے، CI تصدیق کرتا ہے کہ تبدیل شدہ فائلیں متوقع سیٹ سے ملتی ہیں اور متاثرہ ماڈیولز کے لیے ٹیسٹ چلاتا ہے۔ یہ برانچوں کے درمیان تبدیلیاں منتقل کرتے وقت رجعت کے خطرے کو کم کرتا ہے۔