سير عمل Git لمطور PHP: دليل عملي لتجنب كوارث الإنتاج

سير عمل Git لمطور PHP: من الفوضى إلى النظام (والعودة)

هل سبق لك أن دفعت (push) كودًا إلى master مساء الجمعة، وأنت تدعو الله أن يعمل كل شيء؟ أو وقعت في مشكلة composer.lock بعد دمج (merge) كسر كل شيء؟ مرحبًا بك في النادي. Git ليس مجرد نظام للتحكم في الإصدارات، بل هو أداتك اليومية. لكن بدون سير عمل صحيح، حتى أفضل كود PHP يتحول إلى قرع.

في هذا المقال، سنشرح سير عمل Git لمطوري PHP الذي يعمل فعليًا: من اختيار استراتيجية الفروع إلى النشر. لا حشو، فقط كود وأمثلة ونصائح. هيا بنا!

1. اختر استراتيجيتك: Git Flow أم Trunk-Based

الجدل بين Git Flow و Trunk-Based Development أطول من تاريخ أطر عمل PHP. لكن بالنسبة لمعظم مشاريع PHP (خاصة القديمة على Symfony/Laravel)، يظل Git Flow المعيار الذهبي. لماذا؟

\n
• عزل واضح للميزات والإصدارات والإصلاحات العاجلة.
\n
• تحكم كامل فيما يتم نشره في الإنتاج.
\n
• التعامل مع Composer — لا حاجة لدمج فرع التطوير (dev) في كل مرة.
\n

لكن إذا كان لديك خدمات مصغرة و CI/CD متقدم، فإن Trunk-Based خيار جيد أيضًا. سنركز هنا على الطريقة الكلاسيكية.

2. Feature Branch: ملعبك الخاص

كل ميزة جديدة — فرع منفصل. يجب أن يكون الاسم واضحًا: feature/PROJ-123-add-payment-gateway. لا تستخدم أسماء مثل fix-bug أو new-stuff.

مثال لبدء العمل:

git checkout -b feature/PROJ-42-new-cache-system develop\ngit push origin feature/PROJ-42-new-cache-system

أثناء كتابة الكود، لا تنسَ Composer. إذا أضفت تبعية جديدة، قم بإضافة (commit) ملفي composer.json و composer.lock معًا. هذا سينقذ زملاءك من سؤال "لماذا لا يعمل عندي؟"

composer require predis/predis\ngit add composer.json composer.lock\ngit commit -m "PROJ-42: Add predis for caching"

هام: لا تقم بإضافة مجلد vendor/! أضفه إلى ملف .gitignore فورًا.

3. Pull Request: مراجعة كود بدون ألم

عندما تكتمل الميزة، أنشئ PR (أو MR في GitLab) إلى فرع develop. إليك قائمة تحقق ستنقذ أعصاب المراجع:

\n
• ✅ الكود يجتاز phpcs و phpstan (مستوى 6 على الأقل).
\n
• ✅ تمت كتابة الاختبارات (PHPUnit, Pest).
\n
• ✅ تم تحديث composer.lock.
\n
• ✅ لا توجد تعارضات مع فرع develop.

مثال لسكريبت CI (GitHub Actions):

name: PHP CI\n\non:\n  pull_request:\n    branches: [ develop ]\n\njobs:\n  php-tests:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v3\n      - name: Install dependencies\n        run: composer install --no-interaction --prefer-dist\n      - name: Run PHPStan\n        run: vendor/bin/phpstan analyse src --level=6\n      - name: Run tests\n        run: vendor/bin/phpunit

سير العمل هذا لمطوري PHP يؤتمتة فحص الكود حتى قبل أن ينظر أحد إلى PR. سحر، أليس كذلك؟

4. فرع الإصدار: التحضير للإنتاج

عندما تتراكم ميزات كافية للإصدار، أنشئ فرع release/x.y.z من develop. هنا تقوم بإصلاح الأخطاء، تحديث سجل التغييرات (changelog)، وزيادة رقم الإصدار في ملف composer.json.

git checkout -b release/1.2.0 develop\n# إصلاح الأخطاء وتحديث الإصدار\nvim composer.json  # تغيير "version": "1.2.0"\ngit commit -am "Bump version to 1.2.0"\n# الدمج في master و develop\ngit checkout master\ngit merge --no-ff release/1.2.0\ngit tag -a v1.2.0 -m "Release version 1.2.0"\ngit push origin master --tags

لاحظ استخدام --no-ff. هذا يحافظ على تاريخ الفروع، لتتمكن دائمًا من معرفة مصدر الكود.