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 ...) شامل کرتا ہے، جو تاریخ میں تبدیلیوں کی اصل کو ٹریک کرنا آسان بناتا ہے۔

# ہیش کے ذریعے ایک کمٹ کو چیری پِک کریں
git cherry-pick a1b2c3d

# متعدد کمٹ کو چیری پِک کریں (ترتیب وار)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# خودکار کمٹ کے بغیر چیری پِک کریں
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 کمٹ کو چیری پِک کریں (والد متعین کریں)
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 کے ذریعے کون سے کمٹ منتقل کیے گئے۔