AR
RU
EN
ES
ZH
FR
DE
PT
HI
سير عمل Git لمطوري PHP: كيف تتوقف عن الخوف من التعارضات وتحب مراجعة الكود
\n\nهل سبق لك أن أمضيت نصف يوم في دمج الفروع، لتحصل في النهاية على "خطأ فادح" في بيئة الإنتاج؟ أو ربما قام زميلك بدفع كود "خام" عن طريق الخطأ مباشرة إلى master، وعرفت بذلك عندما تعطل الموقع؟ إذا كان الأمر كذلك - مرحباً بك في النادي. لكن الخبر السار هو أن 90% من هذه المشاكل تُحل من خلال سير عمل Git الصحيح لمطوري PHP.
\n\nفي هذه المقالة، لن نعيد سرد الوثائق. سنناقش سيناريوهات حقيقية: كيفية تنظيم الفروع، ومتى نستخدم rebase ومتى نستخدم merge، وكيفية إعداد العمليات بحيث لا يرتبك الفريق في الـ commits. هيا بنا!
\n\nلماذا "git add . && git push" هو شر
\n\nالعديد من مطوري PHP، خاصة في البداية، يستخدمون Git كـ "فلاشة سحابية". يقومون بعمل commit لكل شيء بشكل عشوائي، ولا يكتبون رسائل ذات معنى، ويدفعون مباشرة إلى master. هذا يعمل تماماً حتى أول تعارض أو حتى اللحظة التي تحتاج فيها إلى التراجع عن تغيير.
\n\nيجب أن يحل سير عمل git php الصحيح ثلاث مهام:
\n- \n
- عزل التغييرات - بحيث لا تكسر الميزة أو إصلاح الخلل الكود العامل. \n
- الشفافية - بحيث يفهم أي مطور ما يحدث في المشروع. \n
- الأتمتة - بحيث يتم تشغيل الاختبارات وأدوات التحليل قبل وصول الكود إلى بيئة الإنتاج. \n
دعنا نرى كيفية تحقيق ذلك عملياً.
\n\nاختيار استراتيجية التفرع: Git Flow، GitHub Flow أم شيء خاص بك؟
\n\nلمشاريع PHP، لا توجد إجابة واحدة صحيحة. كل شيء يعتمد على حجم الفريق وتكرار الإصدارات. لكن هناك نموذجان شائعان.
\n\nGit Flow - الكلاسيكية للمشاريع الكبيرة
\n\nإذا كنت تعمل على تطبيق متجانس بإصدارات واضحة (مثل إصدار مرة في الشهر)، فإن Git Flow هو خيارك. الفروع الرئيسية:
\n- \n
master- فقط الكود المستقر المطابق لبيئة الإنتاج. \n develop- فرع التكامل لجميع الميزات. \n feature/*- كل ميزة جديدة. \n release/*- التحضير للإصدار. \n hotfix/*- الإصلاحات العاجلة. \n
مثال لمطور PHP: أنت تكتب وحدة دفع. تنشئ فرع feature/payment-module من develop. بعد الانتهاء - طلب سحب إلى develop. عندما تتراكم ميزات كافية - تنشئ release/2.3.0، حيث فقط إصلاحات الأخطاء. ثم تدمج في master و develop.
GitHub Flow - للتكرارات السريعة
\n\nإذا كان لديك خدمات مصغرة أو تنشر عدة مرات في اليوم، فإن GitHub Flow أبسط:
\n- \n
main(أوmaster) - دائماً جاهز للنشر. \n - أي فرع آخر - لميزة أو إصلاح خلل. \n
- بعد طلب السحب والمراجعة - يتم الدمج مباشرة في
main. \n
بالنسبة لـ PHP، هذا مناسب بشكل خاص عندما يكون لديك CI/CD مهيأ: بعد الدمج في main، يتم تشغيل الاختبارات والنشر تلقائياً إلى staging أو production.
\n\nكتابة commits ذات معنى: أمثلة بلغة PHP
\n\nالـ commit ليس مجرد "حفظ". إنه وثيقة ستستخدمها أنت وزملاؤك لاستعادة التاريخ. استخدم conventional commits:
\n\nfeat: add payment processing via Stripe\nfix: correct SQL query in user repository\nrefactor: extract validation logic to trait\nوالآن تخيل أنك تعمل على مشروع PHP باستخدام Laravel. لنفترض أنك أضفت أمر Artisan جديد. أي commit سيكون مفيداً؟
\n\nfeat: add artisan command to sync expired subscriptions\n\n- Created SyncExpiredSubscriptions command\n- Added subscription:sync tag to schedule\n- Updated Subscription model with scopeExpired\nبعد شهر، ستتمكن من العثور بسرعة على متى ولماذا تمت إضافة هذا الأمر.
