ما هو تطوير الفرع الرئيسي (trunk-based development) وكيف يدعم CI/CD؟

Question

Accepted Answer

**تطوير الفرع الرئيسي** هو إستراتيجية فروع حيث يقوم المطورون بدمج تغييرات صغيرة **بشكل متكرر في فرع رئيسي واحد (trunk)**، باستخدام فروع قصيرة الأجل جداً (أو الالتزام المباشر). يرتبط ارتباطاً قوياً بـ CI/CD عالي الأداء لأنه يزيد من التكامل المستمر.

## ما هو تطوير الفرع الرئيسي

```text
Developers commit small, frequent changes to a SINGLE shared branch (trunk/main):
  → very SHORT-LIVED branches (merged within hours or a day) — or commit directly
  → integrate continuously (multiple times a day) into trunk
  → trunk is kept always RELEASABLE (working, deployable)
→ vs long-lived feature branches that diverge for days/weeks before merging.
```

## لماذا يدعم CI/CD بشكل جيد

```text
✓ MAXIMIZES continuous INTEGRATION — frequent small merges = the essence of CI
  (catch integration issues immediately; tiny, easy-to-resolve conflicts)
✓ AVOIDS "merge hell" — no long-lived branches diverging → no big painful merges
✓ Small changes = lower risk, easier review, faster feedback
✓ Keeps trunk always deployable → enables continuous DELIVERY/deployment
→ Research (DORA) links trunk-based development to high delivery performance.
```

## التعامل مع العمل غير المكتمل

```text
How to commit to trunk frequently when features aren't done?
  ✓ FEATURE FLAGS → merge incomplete features hidden behind off flags (don't break trunk)
  ✓ Break work into small, independently-mergeable, non-breaking pieces
  ✓ Branch by ABSTRACTION → introduce changes incrementally behind abstractions
→ The discipline: integrate small, keep trunk working, hide incomplete work.
```

## تطوير الفرع الرئيسي مقابل feature-branch (Git Flow)

```text
TRUNK-BASED → short-lived branches, frequent integration, continuous delivery,
  feature flags — favored for high-velocity CI/CD
GIT FLOW (long-lived branches) → more structured, release-oriented, but longer
  divergence and bigger merges → less continuous
→ Trunk-based is generally preferred for true CI/CD; Git Flow for scheduled releases.
```

## لماذا تهم هذه المعرفة

فهم تطوير الفرع الرئيسي هو معرفة قيمة على مستوى أعلى لأنه **يرتبط بقوة بـ CI/CD عالي الأداء** ويمثل فلسفة فروع مهمة، لذا فهو مفيد لفهم ممارسات التسليم الفعّالة.

الفكرة الأساسية — دمج المطورين **تغييرات صغيرة بشكل متكرر في فرع رئيسي واحد** باستخدام فروع قصيرة الأجل جداً (بدلاً من فروع ميزات طويلة الأجل تتباعد لأيام أو أسابيع) — **تزيد بشكل مباشر من التكامل المستمر**، وهي جوهر CI: دمج صغير متكرر يكتشف مشاكل التكامل على الفور وينتج عنه نزاعات صغيرة وسهلة الحل، **تجنب "جحيم الدمج"** للفروع المتباعدة بشكل كبير.

فهم **لماذا يدعم CI/CD بشكل جيد** (زيادة التكامل، تجنب الدمج الكبير المؤلم، إبقاء التغييرات صغيرة وقليلة الخطورة، وإبقاء الفرع الرئيسي جاهزاً للنشر دائماً لتمكين التسليم المستمر) يشرح لماذا يُفضل للتسليم عالي السرعة — وملحوظ، **بحث DORA يربط تطوير الفرع الرئيسي بأداء التسليم العالي**، مما يعطيه الدعم التجريبي.

فهم **كيفية التعامل مع العمل غير المكتمل** أثناء الالتزام المتكرر بالفرع الرئيسي — استخدام **feature flags** (دمج الميزات غير المكتملة المخفية خلف أعلام مطفأة بحيث يبقى الفرع الرئيسي يعمل)، تقسيم العمل إلى أجزاء صغيرة قابلة للدمج بشكل مستقل، والفرع بالتجريد — هي الانضباط العملي الرئيسي الذي يجعل تطوير الفرع الرئيسي ممكناً (يتطلب هذه التقنيات لدمج العمل غير المكتمل دون كسر الفرع الرئيسي).

فهم **التناقض مع فروع الميزات/Git Flow** (تطوير الفرع الرئيسي للتسليم المستمر عالي السرعة؛ فروع Git Flow طويلة الأجل لإصدارات منظمة أكثر لكن أقل استمراراً، مجدولة) يعكس حكماً سليماً حول إستراتيجية الفروع.

بما أن تطوير الفرع الرئيسي هو نهج الفروع الذي يدعم بشكل أفضل التكامل والتسليم المستمر الحقيقي (مع البحث الذي يربطه بأداء عالية)، وبما أن فهمه، لماذا يدعم CI/CD، وكيفية ممارسته (feature flags، تغييرات صغيرة) يعكس فهماً لتسليم عالي الأداء، فإن فهم تطوير الفرع الرئيسي هو معرفة قيمة على مستوى أعلى — ممارسة مهمة مرتبطة بـ CI/CD فعّال، تعكس نضج ممارسات التسليم المتوقع للأدوار العليا التي تشكل كيفية دمج وتسليم الفرق.