الموافقة / الحصول على الموافقة: ما هي، الموافقة ومراجعة الكود في Git

ما هي موافقة pull request

الموافقة هي مراجعة إيجابية على pull request، مما يعني أن المراجع قد تحقق من الكود، ولم يجد مشاكل حرجة، ويعتبر التغييرات جاهزة للدمج. في واجهة GitHub، هذا هو الزر الأخضر «Approve» على صفحة PR. بعد الموافقة، يمكن للمؤلف (أو أي عضو لديه صلاحيات الكتابة) تنفيذ الدمج.

عملية الموافقة هي جزء من Branch Protection Rules. يقوم أصحاب المستودع بتكوين المتطلبات الإلزامية: العدد الأدنى للموافقات (على سبيل المثال، 1 أو 2)، من يمكنه الموافقة (مالكو الكود، أعضاء الفريق)، وهل يجب إعادة الموافقة على PR بعد التغييرات (Dismiss stale reviews). بدون تكوين القواعد، الموافقة اختيارية، ولكن في الفرق المهنية هي إلزامية.

يستخدم GitLab آلية مماثلة تسمى Approval Rules. في GitLab، يمكنك تكوين عدد الموافقات المطلوبة من مجموعات مختلفة (على سبيل المثال، 2 من مطوري الباكيند و 1 من DevOps). بعد الحصول على جميع الموافقات الإلزامية، يتم فتح PR تلقائيًا للدمج شريطة أن يكون خط أنابيب CI/CD أخضر.

أنواع المراجعة: Approve، Request Changes، Comment

في GitHub و GitLab ثلاثة أنواع من المراجعات التي يمكن للمراجع تركها على pull request. كل نوع له حالة وعواقب مختلفة لعملية الدمج. Approve أخضر، Request Changes أحمر، Comment رمادي محايد. يعتمد الاختيار على جودة الكود واستعداد التغييرات للقبول.

Approve — يؤكد المراجع: الكود مكتوب بشكل صحيح، ويتوافق مع المعايير، ولا يحتوي على أخطاء واضحة، ويمكن دمجه. Approve لا يعني أن الكود مثالي — فقط أنه جيد بما يكفي للإنتاج. إذا كانت هناك ملاحظات بسيطة (أسلوب، تسمية)، يمكن تركها كتعليقات بدون حجز PR.

Request Changes — يجد المراجع مشاكل يجب إصلاحها قبل الدمج: أخطاء منطقية، ثغرات، انتهاكات في المعمارية، نقص في الاختبارات. بعد Request Changes، يتم حجز PR، ويلزم إعادة الموافقة من نفس المراجع لفتحه (إذا كانت خيار Dismiss stale reviews مفعلة عند التزامات الجديدة).

• Approve — الكود جاهز للدمج، يمكن الدمج بعد اجتياز CI.
• Request Changes — تصحيحات إلزامية، PR محجوز حتى إعادة المراجعة.
• Comment — ملاحظة عامة أو اقتراح دون حجز PR.

تكوين قواعد الموافقة في المستودع

Branch Protection Rules هي آلية GitHub للتحكم في جودة الدمج. تتم التكوين في Settings → Branches لكل فرع محمي (main، develop، release/*). المعلمات الرئيسية: عدد الموافقات الإلزامية، مالكو الكود (CODEOWNERS)، التحقق الإلزامي من CI/CD، وحظر الدفع بدون PR.

المعلمة Dismiss stale pull request approvals تقوم بإزالة الموافقات تلقائيًا إذا تمت إضافة تزام جديد إلى PR. يضمن ذلك أن المراجعين يوافقون على نفس إصدار الكود الذي سيتم دمجه. بدون هذه التكوينة، يمكن للمؤلف إضافة كود جديد بعد الموافقة وسيصل إلى main دون إعادة التحقق.

CODEOWNERS — ملف في جذر المستودع يعين المسؤولين عن مختلف الدليلات. إذا قام PR بتأثير ملفات تنتمي لمالك الكود، تصبح موافقته إلزامية. يسمح CODEOWNERS بتوزيع مناطق المسؤولية: مطورو iOS مسؤولون عن ملفات Swift، DevOps عن تكوينات Docker، المختبرون عن سيناريوهات الاختبار.

# ملف CODEOWNERS مثالي في جذر المستودع

# مطورو iOS هم مالكو كود Swift
*.swift @team/ios-developers

# DevOps هو مالك تكوين CI/CD
.github/workflows/* @devops-team

# مهندسو QA يراجعون الاختبارات
**/tests/* @qa-engineers

# المالكون الافتراضيون لكل شيء آخر
* @tech-leads

مراجعة الكود قبل الموافقة: ما يجب التحقق منه

مراجعة الكود قبل الموافقة هي فحص منظم للكود، وليس نظرة سريعة على الفرق. تشمل مراجعة الكود الجيدة التحقق من المعمارية، والمنطق، والأسلوب، والاختبارات، والأمان. بدون هذا التحقق، تصبح الموافقة مجرد إجراء شكليًا وليست أداة للتحكم في الجودة.

ما يتم التحقق منه أولاً: منطق التغييرات — هل يحل الكود المهمة، هل هناك آثار جانبية، هل معالجة الحالات الحدية صحيحة. الاختبارات — هل تغطي الاختبارات الجديدة جميع السيناريوهات، هل تجتاز الاختبارات القائمة بعد التغييرات. الأمان — هل هناك حقن SQL، XSS، تسريب بيانات حساسة.

ما لا ينبغي أن يكون موضوع المراجعة: أسلوب التنسيق (لذلك توجد linters و formatters)، القرارات المعمارية المتخذة مسبقًا (تتم مناقشتها قبل كتابة الكود). إذا تجاوزت المراجعة 400 سطر أو استغرقت أكثر من ساعة، فهذا مؤشر على أن المهمة كبيرة جدًا وتتطلب تحليلاً. أفضل ممارسات المراجعة — أجزاء من 200–400 سطر خلال 24 ساعة من إنشاء PR.

• المنطق — صحة الحل، معالجة الأخطاء، الحالات الحدية.
• الاختبارات — تغطية السيناريوهات الجديدة، نجاح الاختبارات القائمة، عدم وجود اختبارات flaky.
• الأمان — عدم وجود حقن، تهريب المخرجات، التحكم في الوصول إلى البيانات.
• الأداء — كفاءة الخوارزميات، الاستعلامات الزائدة، تسرب الذاكرة.
• التوثيق — هل التوثيق محدث، هل التعليقات في الأقسام المعقدة واضحة.

سير العمل بالموافقة في الفريق

يبدو سير العمل النموذجي مع الموافقة في فريق من 5–10 مطورين كالآتي: يقوم المطور بإنشاء PR، ويعين المراجعين (عادةً 1–2 شخص من الفريق أو مالكي الكود)، ويقوم CI/CD بتشغيل الفحوصات التلقائية. بعد الحصول على جميع الموافقات الإلزامية و CI أخضر، يقوم المؤلف بالدمج. يتراوح الوقت من إنشاء PR حتى الدمج من ساعتين إلى يومين حسب التعقيد.

تسمح GitHub Actions بأتمتة الدمج بعد الموافقة. إذا كانت قواعد الفروع مكونة، يقوم GitHub بحجز الدمج حتى تتحقق جميع الشروط. تستخدم بعض الفرق bors-ng أو Mergify — روبوتات تقوم بدمج PR تلقائيًا بعد الحصول على جميع الموافقات واجتياز CI. يعمل ذلك على تسريع العملية واستبعاد العامل البشري في الدمج.

النهج الحديث هو trunk-based development مع فروع قصيرة العمر. في هذا سير العمل، يجب الحصول على الموافقة خلال بضع ساعات، وإلا تعتبر المهمة قديمة وتتطلب إعادة مزامنة مع main. تسعى الفرق ذات ثقافة المراجعة العالية إلى وقت موافقة لا يتجاوز 4 ساعات عمل.

أخطاء الموافقة وكيفية تجنبها

أكثر الأخطاء شيوعًا هو الموافقة الشكلية دون فحص الكود الفعلي. عندما يكون PR كبيرًا أو الموعد النهائي قريبًا، قد يضغط المراجع على Approve دون التدقيق في التغييرات. هذا يقلل من قيمة عملية مراجعة الكود بأكملها. الحل: تحديد حد لحجم PR (لا يتجاوز 400 سطر) واستخدام أدوات تحليل الكود (SonarQube، CodeClimate) للتحقق التلقائي.

الخطأ الثاني هو الموافقة الشديدة التشديد. توقع الكود المثالي يعطل التطوير. قد يطلب المراجعون أحيانًا تصحيح ملاحظات أسلوبية لا تؤثر على الجودة. الحل: الفصل الواضح بين الملاحظات الإلزامية (الحاجزة) والاقتراحات الاختيارية (تعليقات). يسمح GitHub بتحديد ما إذا كان التعليق حاجزًا أم لا.

الخطأ الثالث هو الموافقة دون التحقق من CI/CD. حتى إذا كان الكود يبدو صحيحًا، قد لا يتجمع أو يفشل في الاختبارات. تقوم Branch Protection المكونة تلقائيًا بحجز الدمج في حالة CI أحمر، ولكن بعض الفرق تعطل هذه الحماية للسرعة. الحل: تحقق دائمًا من حالة CI قبل الموافقة ولا توافق أبدًا على PR بخط أنابيب أحمر.

• الموافقة الشكلية — عدم وجود فحص فعلي للكود. الحل: حد 400 سطر لكل PR.
• التشديد المفرط — حجز بسبب ملاحظات أسلوبية. الحل: التقسيم إلى حاجز واختياري.
• تجاهل CI — الموافقة عند خط أنابيب أحمر. الحل: تحقق دائمًا من حالة الاختبارات.
• تعيين المؤلف — الموافقة من مؤلف PR. الحل: تكوين Branch Protection ضد المؤلف.