انتقل إلى المحتوى

CODEOWNERS

ملف CODEOWNERS يحدّد من المسؤول عن كل مسار في الـ repository، فيضيف ليڤانت غيت (LevantGit) هؤلاء reviewers تلقائيًا على كل pull request يمسّ ملفاتهم. تحتاجه حين يكبر المشروع ويصعب تذكّر من يراجع ماذا، أو حين تريد ألّا يمرّ تعديل في جزء حسّاس دون أن يراه صاحبه.

ما الذي يفعله الملف؟

الـ CODEOWNERS ملف نصي يربط أنماط مسارات بمستخدمين أو teams. عندما يُفتح pull request يفحص ليڤانت غيت الملفات المتغيّرة فيه، ويطلب review من كل شخص أو team تطابق مسؤوليته تلك الملفات. هذا يوفّر عليك تعيين الـ reviewers يدويًا، ويضمن ألا يمرّ تعديل في جزء حساس دون أن يراه صاحبه.

يبحث ليڤانت غيت عن الملف في المواضع التالية بهذا الترتيب، ويتوقف عند أول ملف يجده:

  • ./CODEOWNERS
  • ./docs/CODEOWNERS
  • ./.gitea/CODEOWNERS

ملاحظة

يقرأ ليڤانت غيت الملف من الـ branch الهدف للـ pull request (غالبًا main)، لا من branch التعديلات. فعدّله على الـ default branch أولًا.

صيغة الملف

كل سطر قاعدة واحدة:

<regexp rule> <@user or @org/team> [@user or @org/team]...
  • القاعدة تعبير نمطي (regular expression) بصيغة لغة Go، وليس نمط .gitignore كما في GitHub. انتبه لهذا إن نقلت ملف CODEOWNERS من GitHub: النقطة في .go تحتاج تهريبًا، و* وحدها لا تكفي بل تحتاج .*.
  • المسؤول مستخدم (@user1) أو team داخل organization (@org1/team1). يجب أن يكون للمستخدم أو الـ team صلاحية قراءة على الـ repository على الأقل.
  • ابدأ القاعدة بـ ! لجعلها قاعدة سلبية: تطابق كل الملفات ما عدا المحددة.
  • # يبدأ تعليقًا، ويجوز وضعه في نهاية السطر.

مثال كامل:

.*\\.go @user1 @user2 # This is comment

# Comment too
# You can assigning code owning for users or teams
frontend/src/.*\\.js @org1/team1 @org1/team2 @user3

# You can use negative pattern
!frontend/src/.* @org1/team3 @user5

# You can use power of go regexp
docs/(aws|google|azure)/[^/]*\\.(md|txt) @user8 @org1/team4
!/assets/.*\\.(bin|exe|msi) @user9

التهريب (escaping)

يمكنك تهريب الأحرف # والمسافة و\ بوضع \ قبلها:

dir/with\#hashtag @user1
path\ with\ space @user2
path/with\\backslash @user3

أما الأحرف ذات المعنى الخاص في التعابير النمطية (.+*?()|[]{}^$\) فتُهرَّب داخل القاعدة بـ \\:

path/\\.with\\.dots
path/with\\+plus

مثال بسيط لفريق صغير

لنفترض repository فيه واجهة أمامية وواجهة خلفية ووثائق:

# الواجهة الخلفية
backend/.* @layla

# الواجهة الأمامية
frontend/.* @omar @org/frontend

# الوثائق: يراجعها الفريق كله
docs/.* @org/docs

عند فتح pull request يغيّر ملفًا في frontend/ سيضاف عمر و team الواجهة الأمامية reviewers تلقائيًا.

الإلزام بالمراجعة

إضافة الـ reviewers تلقائيًا لا تمنع الـ merge وحدها. إن أردت أن يكون approve هؤلاء الـ reviewers شرطًا للـ merge فاجمع بين CODEOWNERS وProtected branches: فعّل حماية الـ default branch واطلب عددًا من الـ required approvals قبل الـ merge.

نصيحة

إن لم يُضَف الـ reviewers كما توقعت فتحقق من: موضع الملف واسمه، وأنه على الـ branch الهدف، وأن التعبير النمطي صحيح (جرّبه في أي أداة اختبار تعابير نمطية بصيغة Go)، وأن المستخدم أو الـ team له صلاحية على الـ repository.

ماذا بعد؟

  • Protected branches: اجعل الـ approve شرطًا للـ merge.
  • Permissions: ماذا يستطيع كل collaborator أو team أن يفعل.
  • Pull requests: دورة حياة الـ pull request من الفتح إلى الـ merge.

هذه الصفحة مبنية على وثائق Gitea (رخصة MIT) بعد ترجمتها وتبسيطها.