احمِ فرع main بقواعد GitHub: موافقة واحدة لا توقف كل تجاوز

لحماية فرع main، أنشئ branch ruleset يستهدف الفرع، وتحقق من تفعيل منع الحذف والدفع القسري، ثم اشترط طلب دمج وفحوص حالة ناجحة. تتيح قواعد GitHub المتاحة للفروع إضافة مراجعات وتوقيعات للالتزامات، كما تسمح بتحديد جهات تتجاوز القاعدة؛ لذلك لا تكفي موافقة واحدة إذا كانت صلاحية التجاوز أوسع مما تقصده.

اختر مستوى المراجعة بحسب من يعمل في المستودع: يستطيع المطور الفردي اشتراط طلب الدمج والفحوص من دون انتظار مراجع بشري غير موجود، بينما يستطيع الفريق اشتراط موافقة من شخص آخر. وقبل تفعيل القاعدة، تأكد من أنها تستهدف main فعلاً، وأن الفحوص المختارة تعمل، وأن قائمة التجاوز لا تمنح طريقاً دائماً إلى الفرع لكل من يملك حق الكتابة.

أنشئ قاعدة تستهدف main وتمنع تغيير تاريخه

افتح Settings في المستودع، ثم Rulesets، واختر New ruleset ثم New branch ruleset. تتطلب إدارة قواعد المستودع صلاحية المسؤول أو دوراً مخصصاً يجيز تعديلها. امنح القاعدة اسماً واضحاً، وحدد main ضمن Target branches؛ وإذا اخترت استهداف الفرع الافتراضي بدلاً من اسمه، فستتبع القاعدة الفرع الافتراضي حين يتغير. راجع أن أي نمط استبعاد لا يستثني main بالخطأ.

1. تحقق من تفعيل Restrict deletions وBlock force pushes ضمن Branch protections. الأولى تقيد حذف الفرع المستهدف، والثانية تمنع الدفع القسري الذي قد يزيل التزامات بنى عليها آخرون عملهم.
2. فعّل Require a pull request before merging. هذا يربط التغييرات بطلب دمج، لكنه لا يفرض موافقة بشرية ما لم تضبط شرط المراجعة أيضاً.
3. فعّل Require status checks to pass before merging، وأضف أسماء الفحوص التي يرسلها مسار الاختبارات فعلياً. فالفحص المطلوب الذي لا تصله نتيجة ناجحة سيمنع الدمج المعتاد.
4. افحص Bypass list قبل اختيار Active. سجّل كل جهة تحتاج الاستثناء وسبب حاجتها إليه، واترك القائمة خالية إن لم توجد مهمة محددة تتطلبه.

لا تستخدم Restrict updates بديلاً تلقائياً لطلب الدمج؛ فهو يقصر تحديث الفرع المستهدف على الجهات المخولة بالتجاوز، وقد يعطل مسار العمل الذي تريد السماح به. كذلك لا تفترض أن كتابة اسم وظيفة من ملف إعداد الاختبارات تكفي: طابق اسم الفحص مع النتيجة التي تظهر في طلب دمج حقيقي. إذا أردت أن تأتي النتيجة من تطبيق GitHub بعينه، فيمكن تحديده مصدراً متوقعاً للفحص، بعد التأكد من تثبيته وإرساله ذلك الفحص.

اختر المراجعة التي يستطيع فريقك توفيرها

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

عندما يعمل أكثر من شخص على المستودع، اشترط موافقة واحدة على الأقل من مراجع مخوّل. وإذا أردت أن تشمل الموافقة أحدث تعديل على الشيفرة، فعّل Dismiss stale pull request approvals when new commits are pushed؛ عند تغير محتوى الطلب بعد الموافقة، تُسقط GitHub المراجعة القديمة ويحتاج الطلب إلى موافقة جديدة. ويمكن اشتراط موافقة من شخص غير صاحب آخر دفع قابل للمراجعة، وهي طريقة أخرى لربط القرار بأحدث تغيير.

لملفات يملكها فريق محدد، يمكن اشتراط مراجعة مالكي الشيفرة بعد إعداد CODEOWNERS ومنح المالكين صلاحيات مراجعة مناسبة. حدد هذا الشرط حيث توجد مسؤولية واضحة عن الملفات وقدرة فعلية على الرد، بدلاً من فرضه على كل تغيير بلا تمييز. ويبقى طلب الدمج والموافقة والفحص شروطاً مختلفة: وجود أحدها في القاعدة لا يفعّل الآخرين تلقائياً.

شدّد فرع الإنتاج وفق مسار الاختبار والنشر

إذا كان main يحمل نسخة الإنتاج، ففكّر في اشتراط تحديث فرع طلب الدمج مع الفرع الأساسي قبل الدمج. يقلل ذلك احتمال الاعتماد على اختبارات أُجريت قبل وصول تغييرات أخرى إلى main، لكنه قد يستلزم إعادة تشغيل الفحوص بعد دمج طلب سابق. وإذا كان النشر إلى بيئة تجريبية جزءاً من قرار الإصدار، يمكن اشتراط نجاح النشر إليها، بشرط أن تكون البيئة ومسار النشر مستخدمين بالفعل.

تطلب معايير UKHSA الهندسية من فرقها منع الحذف والدفع القسري، وفرض طلب دمج وفحوص ناجحة وموافقة واحدة على الأقل. وتشترط أيضاً تحديث الفرع وإسقاط الموافقات القديمة ومراجعة أحدث دفع ونتائج فحص الشيفرة، بينما توصي بتوقيع الالتزامات. هذه سياسة فرق UKHSA؛ اختر من ضوابطها ما تدعمه أدوات الإنتاج ومسؤوليات المراجعة في مستودعك.

قبل فرض Require signed commits، تأكد من أن المطورين وحسابات الأتمتة ينتجون التزامات موقعة ومتحققاً منها. قد تمنع الالتزامات غير الموقعة في فرع الطلب دمجاً بطريقة squash، حتى عندما يوقّع GitHub التزام الدمج النهائي. وإذا كانت الفحوص تأتي من أكثر من جهة، فحدد ما إذا كان المطلوب نجاح الفحص باسمه فقط أم قبوله من تطبيق بعينه؛ تقييد المصدر يفيد حين تكون هوية الجهة التي ترسل النتيجة جزءاً من الضمان المطلوب.

احصر التجاوز في جهة ومهمة واضحتين

يمكن أن تضم Bypass list دوراً أو فريقاً أو تطبيق GitHub مؤهلاً. تمنح هذه الصلاحية طريقاً لتجاوز شروط القاعدة، ولذلك فإن إضافة دور واسع مثل جميع أصحاب حق الكتابة تُضعف أثر المراجعة والفحوص. سمّ الفريق المسؤول عن الإصلاح الطارئ أو التطبيق الذي تتطلب مهمته استثناءً، وحدد داخل سياسة الفريق متى يستخدمه ومن يراجع استخدامه ومتى تُزال الصلاحية.

تتيح تعليمات GitHub لإنشاء القواعد اختيار For pull requests only لجهة التجاوز. عند اختياره، تفتح الجهة طلب دمج وتستطيع تجاوز حماية الفرع عند دمجه، من دون منحها دفعاً مباشراً دائماً؛ ويبقى مسار التغيير ظاهراً في الطلب وسجل التدقيق. افحص هذا الخيار إذا كانت مهمة الإصلاح الطارئ تحتاج تجاوز شرط بعينه مع الاحتفاظ بطلب الدمج.

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

راقب أثر القاعدة قبل إنفاذها

إذا أتاح إعداد المستودع وضع Evaluate، اختره لمراقبة ما كانت القاعدة ستسمح به أو تمنعه في Rule Insights. هذا الوضع لا يفرض الشروط، فلا تعدّ main محمياً به وحده. راقب طلبات دمج تمثل عمل الفريق المعتاد، ولاحظ ما إذا كان فحص مطلوب لا يصل، أو كانت مراجعة مشروطة تعطل الدمج، أو ظهرت جهة تستخدم التجاوز.

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

اقرأ أيضًا:

• تجاوز دخل عملك مليون درهم؟ موعد التسجيل لا يتبع يوم التجاوز
• Cursor أم GitHub Copilot؟ نوع المهمة أهم من فرق 10 دولارات
• ترخيص «موثوق» في السعودية: إعلان الأجهزة الطبية يحتاج موافقة ثانية