تخطَّ إلى المحتوى

صحة Git - نظافة المستودع

تنظر «صحة Git» في كيفية استخدام المستودع لا في الشيفرة داخله: الفروع المهجورة، والدمج بلا مراجعة، والدفع القسري إلى الفروع المحمية، والإيداعات الضخمة وإشارات نظافة مشابهة.

  • تعمل من جهة الخادم مقابل مزود Git باستخدام بيانات اعتماد المشروع المتصلة - بلا عميل جمع وبلا خطوة CI. كل مشروع له بيانات اعتماد مشمول. المزودون الأربعة مشمولون - GitLab وGitHub وBitbucket Cloud وAzure DevOps Repos؛ القاعدة التي لا يستطيع مزود الإجابة عنها (مثل الحذف الافتراضي لفرع المصدر في Bitbucket) تُتخطى ولا تُعد فاشلة.
  • توضع الفحوصات في طابور وتعالج في الخلفية؛ يمكن إطلاقها من المشروع أو تركها للفحوصات المجدولة.
  • كل قاعدة تنتج نتيجة بإحدى أربع حالات، ودرجة المشروع مجموع موزون - الدفع القسري أثقل من ملاحظة تسمية.

شروط الدمج وقواعد الدفع

Section titled “شروط الدمج وقواعد الدفع”

إلى جانب حماية الفرع نفسها، يقرأ Git Health ما يتطلبه الدمج فعليًا وما لا تزال الحماية تسمح به:

  • الموافقات - يحتاج طلب الدمج إلى موافقة واحدة على الأقل، وإلى موافقتين على الأقل، ولا يستطيع كاتبه الموافقة عليه بنفسه.
  • شروط الدمج - يتطلب الدمج خط أنابيب ناجحًا ونقاشات محلولة.
  • الدفع إلى الفرع الافتراضي - لا دفع قسري (force push)، ولا دفع مباشر يتجاوز طلب الدمج. قد يظل الفرع المحمي يسمح للمشرفين (maintainers) أو لأشخاص مسمّين على الفرع بالدفع المباشر: هذا يُحتسب بنصف الدرجة؛ أما إذا كان المطورون قادرين على الدفع فلا يُحتسب شيء. الفرع غير المحمي يُبلَّغ عنه مرة واحدة، عبر قاعدة حماية الفرع؛ وتنتظر قاعدتا الدفع حتى يصبح الفرع محميًا.
  • الوسوم - وسم واحد على الأقل محمي، حتى لا يمكن نقل إصدار منشور أو حذفه. إذا كان المشروع يتتبع إصداراته بالوسوم، فإن قاعدة حماية الإصدارات تفحص هذه الوسوم وتتنحى هذه القاعدة.

تُقرأ هذه البنود على GitLab وGitHub؛ أما Bitbucket Cloud وAzure DevOps فيحفظانها في سياسات فروع لا تُقرأ بعد، لذا لا تُطبَّق القواعد هناك. تُقرأ حماية الوسوم على GitLab فقط.

تبحث قواعد خط الأنابيب أيضًا، إلى جانب فحص الأسرار والتبعيات، عن خطوة تحليل أمني ثابت (SAST)، وفحص صور الحاويات، وقائمة مكوّنات برمجية مُولَّدة (CycloneDX أو SPDX). تُقرأ الملفات المُضمَّنة أيضًا، ومنها قوالب GitLab: قوالب GitLab لفحص التبعيات والحاويات تُولِّد بنفسها قائمة SBOM بصيغة CycloneDX. تُفحص قوالب طلبات الدمج والمشكلات كملفات في المستودع.

  • درجة المشروع وتقديره مع النتائج خلفها؛ كل نتيجة تشرح ما لوحظ ولماذا يهم.
  • عرض مساحة العمل - أي المشاريع مشمولة وأيها لم يفحص قط (لم يفحص قط يبلغ عنه بوصفه غير معروف، لا سليما).
  • تعرض منطقة الإدارة الصورة نفسها على مستوى التنصيب كله.

مفاتيح المهام وSonar والإصدارات

Section titled “مفاتيح المهام وSonar والإصدارات”
  • قاعدة الفروع تشترط مفتاح مهمة (GIT_BRANCH_RULE_REQUIRES_ISSUE_KEY، GitLab) - تُقرأ قاعدة الدفع في المشروع (branch name regex). تنجح عندما ترفض القاعدة فرعًا بلا مفتاح مهمة (feature/add-login) وتقبل فرعًا به (feature/PROJ-123-add-login أو بأحرف صغيرة feature/proj-123-...). يُحكم على القاعدة بما تفعله بأسماء نموذجية، لا بطريقة كتابتها.
  • نتائج Sonar في طلب الدمج (CI_SONAR_MR_REPORT) - يكتب خط الأنابيب نتيجة SonarQube في طلب الدمج: مهمة تنشرها في الوصف، أو تحليل Sonar الخاص بطلبات الدمج (sonar.pullrequest.key). يُتخطى خط الأنابيب الذي لا يحتوي على SonarQube هنا؛ قاعدة SonarQube تبلغ عن هذه الفجوة.
  • مفاتيح المهام بأحرف صغيرة تُحتسب: bugfix/proj-123 يسمي المهمة بوضوح bugfix/PROJ-123 نفسه في قاعدة تسمية الفروع.
  • ترقيات الإصدار - طلب الدمج الذي يُدخل فرع release/ إلى الفرع الافتراضي يحمل كل مهام الإصدار، لذا يُستثنى من قاعدة عنوان طلب الدمج، كما تُستثنى التزامات الدمج من قاعدة الالتزامات.
  • الحماية بنمط - الفرع المحمي بنمط (release/*) يُعد محميًا في قاعدة فروع الإصدار وفي كل مكان آخر.
  • ملفات القفل يُبحث عنها حتى عمق ثلاثة مجلدات (src/<layer>/<Project>/packages.lock.json)، مجلدات الشيفرة أولًا؛ البحث الذي لم يكتمل يُعد متخطى لا مفقودًا.

لم تعد هذه القواعد تعمل. تبقى نتائج الفحوصات السابقة في السجل؛ وبجانب كل قاعدة القاعدةُ التي تجيب الآن عن السؤال نفسه.

القاعدةحلّت محلهاالسبب
REPO_README_PRESENTالامتثال DOC_README_EXISTSمستندات المستودع يفحصها الامتثال؛ كان الملف الناقص نفسه يُبلَّغ عنه في الوحدتين.
REPO_GITIGNORE_PRESENTالامتثال REPO_GITIGNORE_EXISTSالسبب نفسه.
REPO_SECURITY_MD_PRESENTالامتثال SEC_POLICY_EXISTSالسبب نفسه.