الـ Branching والـ Pull Requests

نعمل بـ GitHub Flow، لا بـ GitFlow. الـ feature branches قصيرة العمر تتفرّع من main، ثم PR واحد، ثم squash-merge، ثم حذف الـ branch. الاستثناء الوحيد هو release branch طويل العمر حين نكون ما زلنا ندعم نسخة أقدم تعمل في production لدى عميل.

تصف هذه الصفحة النيّة. أمّا القواعد فمفروضة فعليًا عبر branch policies في Azure DevOps — تلك هي مصدر الحقيقة، وهذه الصفحة هي الشرح.

نموذج الـ Branch

gitGraph
  commit id: "main"
  branch feature/12345-login
  checkout feature/12345-login
  commit id: "wip"
  commit id: "wip fix"
  checkout main
  commit id: "#12345" tag: "squashed"
  commit id: "..."
  branch release/1.x
  checkout release/1.x
  commit id: "hotfix"

الـ feature branch ينتهي عند هذا الحد — الـ squash-merge يضع commit واحدًا جديدًا على main ويحذف الـ branch. لا يوجد merge commit.

• أسماء الـ branches مرتبطة بعنصر العمل: feature/<id>-short-desc، bugfix/<id>-short-desc، hotfix/<id>-short-desc.
• الـ main جاهز للشحن دائمًا. لا شيء يُدمج دون build أخضر ومراجعة.
• استخدم الـ squash-merge كي يبقى في main commit واحد نظيف لكل عنصر عمل؛ واحذف الـ branch عند الدمج.
• الـ release/x.x موجود فقط لنسخة عميل ما زلنا ندعمها — مخرج الطوارئ الموثّق، لا الوضع الافتراضي.

تدفّق الـ code review

sequenceDiagram
  actor Dev as Developer
  participant PR as Pull Request
  participant CI as Build Validation
  participant Rev as Reviewer
  Dev->>PR: Open PR (small, work item linked)
  PR->>CI: Trigger build + tests
  CI-->>PR: Must be green
  Dev->>Dev: Self-review the diff first
  Dev->>Rev: Request review
  Rev-->>Dev: Comments — "nit" vs "blocking"
  Dev->>PR: Resolve blocking comments
  Rev->>PR: Approve
  Dev->>PR: Squash-merge + delete branch

السياسة (مفروضة، لا اختيارية)

القاعدة	الإعداد	لماذا
PRs صغيرة	الهدف ≤ ~400 سطر مُعدَّل	الـ PRs الكبيرة تُمرَّر بختم دون قراءة.
الحد الأدنى للمُراجِعين	1، مع تعطيل الموافقة الذاتية	التقاط العيوب دون تعطيل التدفّق.
مُراجِعون مطلوبون حسب المسار	قادة الـ backend على backend/** و**/Migrations/** وdevops/**	قابل للفرض كسياسة Automatically included reviewers. أمّا القواعد المبنية على الأقدمية فلا — Azure DevOps لا يستطيع تغيير عدد المُراجِعين حسب كاتب الـ PR.
مُراجِع ثانٍ	اصطلاح، لا سياسة: backend، أو ما يمسّ الأمان، أو كاتب junior	الأداة لا تستطيع فرضه (انظر السطر أعلاه)، لذا يفرضه Team Lead. مذكور في الحلقة اليومية؛ ومتوقَّع من الـ juniors.
Build validation	مطلوب، ويجب أن ينجح	الأخضر يعني كل بوابة مانعة — انظر قائمة البوابات، بما فيها اختبارات الـ backend.
SLA المُراجِع	الردّ في نفس يوم العمل	الـ PR العالق يوقف لوحة التدفّق كلها.
اصطلاح التعليقات	ابدأ التعليق بـ nit: إذا كان غير معطِّل	يفصل «يجب إصلاحه» عن «حبّذا لو».

ملاحظة

اضبط هذه الإعدادات من Azure DevOps ← Repos ← Branches ← main ← Branch policies. إذا غيّرت السياسة، حدّث هذا الجدول في نفس الـ PR.

ما الذي يحتويه وصف الـ PR الجيّد

• ماذا تغيّر ولماذا (اربط عنصر العمل).
• كيف جرى اختباره (اختبارات مضافة، خطوات يدوية).
• صور الشاشة لأي تغيير في الواجهة (Angular / PrimeNG).