git cherry-pick يطبّق commit محدد من فرع على آخر — وينسخ فقط التغييرات من ذلك الـ commit، بدون دمج الفرع بأكمله. وهو مفيد لتطبيق تغييرات معينة بشكل انتقائي، مثل نقل إصلاح إلى إصدارة سابقة.
# apply a specific commit from another branch onto the current branch
git cherry-pick <commit-hash>
# → creates a NEW commit on the current branch with that commit's changes
git cherry-pick <commit1> <commit2>
git cherry-pick A..B
يأخذ cherry-pick التغييرات من commit محدد ويطبّقها كـ commit جديد على الفرع الحالي — بشكل انتقائي، بدون إحضار بقية الفرع المصدر.
✓ BACKPORTING a fix — apply a bug fix from main to a release/maintenance branch
(without merging all of main's other changes into the release branch)
✓ Applying a specific commit that's ready, while the rest of its branch isn't
✓ Moving a commit made on the wrong branch to the correct one
✓ Selectively pulling one change from another branch
⚠️ Creates DUPLICATE commits (same changes, different hashes on each branch):
→ can cause confusion/conflicts if branches are later merged (the change appears twice,
though Git often handles it). Prefer merge/rebase for integrating whole branches.
⚠️ Cherry-picking many commits is a sign you might want a merge/rebase instead
⚠️ Conflicts can occur (resolve like a merge); use it deliberately, not as a default
→ Use cherry-pick for SELECTIVE, specific needs — not routine integration.
فهم git cherry-pick قيّم لـ تطبيق تغييرات معينة بشكل انتقائي، وهي قدرة مفيدة في حالات معينة، لذا فهي معرفة Git عملية تستحق التعلم.
القدرة الأساسية — تطبيق تغييرات commit معين على فرع آخر بدون دمج الفرع بأكمله — تعالج احتياجات حقيقية لا يستطيع الدمج التعامل معها بنظافة.
الاستخدام الأكثر شيوعاً وأهمية هو نقل الإصلاح إلى إصدارة سابقة: تطبيق إصلاح خطأ معين من الفرع الرئيسي على فرع الإصدار أو الصيانة، الحصول على ذلك الإصلاح فقط بدون دمج كل التغييرات الأخرى من main (التي قد تكون غير مستقرة أو غير مُطلقة) في فرع الإصدار — وهي احتياجية متكررة في صيانة البرامج المُطلقة.
الاستخدامات الأخرى تشمل تطبيق commit واحد جاهز بينما بقية فرعه ليست جاهزة، نقل commit تم إنشاؤه على فرع خاطئ إلى الفرع الصحيح، والسحب الانتقائي لتغيير واحد.
فهم التحذيرات مهم لاستخدام cherry-pick بشكل مناسب: يُنشئ commits مكررة (نفس التغييرات برموز hash مختلفة على كل فرع)، مما قد يسبب التباساً أو تضاربات إذا تم دمج الفروع لاحقاً، لذا يجب استخدامه عن قصد لاحتياجات انتقائية بدلاً من كونه طريقة روتينية للتكامل (merge أو rebase أفضل لتكامل الفروع بأكملها)، واستخدام cherry-pick لـ commits عديدة علامة على أنك ربما تريد merge بدلاً من ذلك.
هذا الحكم — استخدام cherry-pick للحالات الانتقائية والمحددة (خاصة نقل الإصلاحات إلى فروع الإصدارات) مع تفضيل merge/rebase للتكامل الروتيني — يعكس ممارسات Git سليمة.
بما أن تطبيق تغييرات محددة بشكل انتقائي (خاصة نقل الإصلاحات إلى فروع الإصدارات) احتياجية حقيقية وحساسة أحياناً، وبما أن cherry-pick هو الأداة لها (مع تحذيرات حول استخدامها المناسب)، فإن فهم git cherry-pick — كيف يعمل، وحالات الاستخدام الرئيسية له مثل نقل الإصلاحات، ومتى يتم استخدامه بدلاً من merge/rebase — معرفة Git عملية وذات صلة لتعامل السيناريوهات ذات التغييرات الانتقائية التي تنشأ في صيانة وإدارة البرامج عبر الفروع.