شرح Git cherry-pick: انسخ commit إلى فرع آخر وحل التعارضات

يطبّق Git cherry-pick التغيير الذي أدخله commit على فرعك الحالي، ويسجّله عادةً في commit جديد. انتقل إلى الفرع الذي يجب أن يستقبل الإصلاح، وافحص commit الأصلي، ثم نفّذ git cherry-pick <commit>. لا يتغير الفرع المصدر. عند التعارض، حل الملفات وتابع أو ألغِ العملية.

تخيّل إصلاح مشكلة دفع على feature/checkout بينما يحتاج فرع الإصدار إلى الإصلاح وحده. قد يجلب دمج الفرع بالكامل عملًا غير مكتمل. يشرح الدليل نقل الإصلاح باستخدام Git وباستخدام GitTree الذي نطوّره لأنظمة macOS وWindows وLinux. تساعدك الواجهة في التأكد من الفرع المستقبِل وفروق commit قبل تطبيقه.

الفرق بين cherry-pick وmerge وrebase

يناسب cherry-pick نقل إصلاح إلى إصدار أقدم أو معالجة commit سُجّل على فرع غير مقصود. لا يناسب استخدامه باستمرار بدل دمج فرعين يحتاجان كل العمل نفسه؛ يصعب تتبع النسخ المتكررة. راجع rebase التفاعلي ودليل شجرة commits للعمل على فروع كاملة.

كيفية نسخ commit إلى فرع آخر

ابدأ بمجلد عمل نظيف. سجّل تعديلاتك غير المكتملة أو احفظها مؤقتًا وفق دليل stash. اجلب التحديثات إذا كان الإصلاح بعيدًا ثم افحص تاريخ المصدر. الأسماء والـhash أمثلة؛ استبدلها بفرع مستقبِل موجود وفرع المصدر ومعرّف الإصلاح الفعلي.

git status
git fetch origin
git log --oneline origin/feature/checkout
git show abc1234
git switch release/2.x
git status
git cherry-pick -x abc1234
git show --stat HEAD
git status

يضيف -x مرجع commit المصدر إلى الرسالة عند نجاح النسخ دون تعارض، ما يساعد في تتبع الإصلاحات المنقولة. يحدّث fetch مراجع الفروع البعيدة ولا يحدّث فرع الإصدار المحلي تلقائيًا. تأكد من أن الفرع المستقبِل عند النسخة المتفق عليها، ثم راجع commit الجديد وشغّل اختبارات الإصدار قبل الرفع.

يحصل commit المنسوخ عادةً على hash مختلف بسبب اختلاف الأب وبيانات commit الأخرى. يبقى الأصل على فرع المصدر. لا تؤدي عملية النسخ إلى إزالته من الفرع الخطأ؛ تنظيف ذلك الفرع قرار مستقل، خصوصًا إذا كان آخرون يستخدمونه.

نزّل GitTree لتطبيق الخطوات باستخدام شجرة مرئية ومحرر تعارضات. تشمل الخطة المجانية cherry-pick والمستودعات الخاصة. سجّل الدخول إلى الإصدار الرسمي الحالي وافتح مستودعك الموجود للعمل على تاريخ Git نفسه.

نسخ عدة commits ونطاقات متصلة

git cherry-pick abc1234 def5678
# A linear range, including the first commit:
git cherry-pick "abc1234^..def5678"

هذان مثالان بديلان. تنفّذ القائمة الصريحة النسخ بالترتيب المكتوب، لذا ضع الاعتماديات أولًا. يتبع النطاق قواعد مجموعات المراجعات وليس الصفوف التي تراها في الشجرة. يستبعد A..B العنصر A، بينما يشمله A^..B في سلسلة خطية بسيطة عندما يكون له أب. استخدم قائمة صريحة مُراجعة عند نقل إصلاح بدل نطاق يمر بعمليات دمج.

حل تعارضات cherry-pick ثم المتابعة

يتوقف Git عندما يعجز عن تطبيق التغيير. نفّذ git status لمعرفة العملية والمسارات المتعارضة ثم حرّر النتيجة المطلوبة. راجع دليل حل التعارضات لأمثلة العلامات والمحرر الثلاثي في GitTree. يحتاج الحل إلى اختبارات حتى بعد إزالة العلامات؛ فقد يستخدم الفرع المستقبِل واجهات مختلفة.

git status
git diff --name-only --diff-filter=U
# Resolve the file, then check and stage it:
git diff --check
git add -- src/payment.ts
git diff --cached
git cherry-pick --continue

قد تتوقف السلسلة عدة مرات عند commits مختلفة. إذا أعلن Git أن النتيجة فارغة، افحص ما إذا كان التغيير موجودًا بالفعل أو أن الحل أزاله. استخدم git cherry-pick --skip فقط عندما تقصد تخطي ذلك commit، فهو ليس حلًا عامًا للتعارضات.

الفرق بين abort وquit وskip

commits الدمج والاعتماديات والتراجع عن النسخ

يحتاج commit الدمج إلى تحديد الأب المرجعي mainline لأن له أكثر من أب. افحصه باستخدام git show --no-patch --pretty=raw <merge> قبل التفكير في git cherry-pick -m 1 <merge>. الأب الأول ليس صحيحًا دائمًا. يطلب GitTree تحديد الأب؛ اختره وفق التاريخ الذي تقيس التغيير بالنسبة إليه، لا كاختيار آلي. غالبًا يكون نسخ commit الإصلاح العادي أوضح.

إذا فشل بناء الإصلاح المنسوخ فراجع اعتمادياته؛ قد توجد دالة مساعدة أو ترحيل قاعدة بيانات أو إعداد في commit سابق. نجاح Git يعني أن التغيير طُبّق فقط. اختبر الفرع المستقبِل. للتراجع عن نسخة مكتملة على تاريخ مشترك استخدم revert لمعرّف commit الجديد على الفرع المستقبِل، وليس معرّف المصدر. للعمل غير المنشور راجع خيارات reset والاستعادة في التراجع عن أخطاء Git قبل تغيير التاريخ.