الفروع واستراتيجيات الفروع

الفرع خط تطوير مستقل. يسمح بالعمل على ميزة جديدة أو تصحيح دون المساس بالشفرة المستقرة التي يستخدمها الآخرون.

فكّر في الفرع كمسودة منفصلة. يمكنك أن تجرّب فيه ما تشاء؛ ما دام لم تدمج، فعمل الآخرين لا يتأثر.

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

الأوامر الأساسية التي رأيناها في الوحدة 01:

# إنشاء فرع والانتقال إليه
git switch -c feature/login

# سرد الفروع
git branch

# العودة إلى main
git switch main

تمرين مصغّر — اكتب الأمر الحديث لإنشاء فرع feature/login والانتقال إليه دفعة واحدة.

في الفريق لا تُنشأ الفروع عشوائياً: نعطيها دوراً واسماً عرفياً. هذه أكثر الأنواع انتشاراً.

أمثلة أسماء واقعية:

feature/ajout-paiement-stripe
feature/dashboard-utilisateur
release/1.4.0
hotfix/correction-faille-login

عرف تسمية جيد توثيق مجاني: من اسم الفرع وحده يعرف الفريق الموضوع.

تمرين مصغّر — يجب أن تصحّح على وجه السرعة ثغرة دخول في الإنتاج. أي بادئة فرع تستخدم، واقترح اسماً كاملاً.

Git Flow استراتيجية منظَّمة قدّمها Vincent Driessen سنة 2010. تقوم على فرعين دائمين (main و develop) وثلاثة أنواع فروع مؤقتة (feature، release، hotfix).

الدورة النموذجية:

1. ننطلق من develop لإنشاء فرع feature/*.
2. بعد الانتهاء تُدمَج الـ feature في develop.
3. عندما تكفي الميزات، ننشئ release/* للتثبيت.
4. تُدمَج الـ release في main (وتُوسَم) و في develop.
5. خطأ حرج في الإنتاج؟ ننشئ hotfix/* من main، ثم ندمجه في main و develop.

# بدء ميزة (بلا إضافة git-flow)
git switch develop
git switch -c feature/panier

# ... عمل + إيداعات ...

git switch develop
git merge feature/panier
git branch -d feature/panier

يتألق Git Flow للبرمجيات المسلَّمة بإصدارات (تطبيقات محمولة، برمجيات مثبَّتة). لموقع ويب يُنشَر 10 مرات في اليوم يصبح عائقاً.

GitHub Flow استراتيجية بسيطة وخفيفة، فكّرت لـ النشر المستمر. فرع دائم واحد: main. الباقي يمر بفروع feature قصيرة وطلبات سحب.

القواعد الذهبية:

1. main قابل للنشر دائماً.
2. لكل عمل ننشئ فرعاً وصفياً من main.
3. نودع بانتظام ونفتح طلب سحب (يُرى في الدرس 03).
4. بعد المراجعة واختبارات خضراء، ندمج في main.
5. ننشر main فوراً.

git switch main
git pull
git switch -c feature/filtre-recherche
# ... إيداعات ...
git push -u origin feature/filtre-recherche
# → فتح طلب سحب على GitHub

GitHub Flow غالباً أفضل نقطة انطلاق لفريق حديث: هيكل كافٍ للتعاون، وخفة كافية للسرعة.

تمرين مصغّر — في GitHub Flow، اكتب الأمرين للانطلاق من main محدَّث قبل إنشاء فرع العمل.

git switch main
git pull

Trunk-Based Development (التطوير على الجذع) يدفع البساطة أبعد: الجميع يدمج عمله في فرع واحد (trunk، أي main) مراراً جداً — مثاليًا عدة مرات في اليوم.

المبادئ الأساسية:

• فروع الميزات صغيرة جداً وتعيش أقل من يوم.
• الميزات غير المنتهية تُخفى خلف feature flags (أعلام) بدل فروع طويلة.
• التكامل المستمر (CI) إلزامي: كل إيداع يشغّل بناء + اختبارات.

# دورة قصيرة جداً
git switch main
git pull
# تعديل صغير...
git commit -am "إضافة زر التصدير"
git push      # مدمج في الجذع بعد دقائق

أسوأ عدو لفرق Git الفروع التي تعيش أسابيع. كلما تأخر الدمج، صار ألماً. يحلّ trunk-based ذلك بالدمج المبكر والمتكرر.

تمرين مصغّر — في Trunk-Based، كيف تدمج ميزة غير منتهية دون إعاقة الآخرين ودون إنشاء فرع طويل؟

لا توجد استراتيجية كونية: الاختيار الجيد يعتمد على نوع المنتج ونضج الفريق ووتيرة النشر.

نصيحة: معظم الفرق ينبغي أن تبدأ بـ GitHub Flow. يقدّم أفضل تسوية بين البساطة والأمان. ننتقل إلى trunk-based عندما ينضج CI، أو إلى Git Flow فقط إذا فرض المنتج إصدارات.

السؤال 1: لماذا يُستخدم فرع Git أساساً؟

a) لنسخ المستودع احتياطياً على السحابة

b) للعمل بمعزل دون التأثير على الشفرة المستقرة

c) لضغط الملفات

d) لحذف السجل

السؤال 2: كم فرعاً دائماً يستخدم Git Flow؟

a) واحد (main)

b) اثنان (main و develop)

c) لا شيء

d) واحد لكل مطوّر

السؤال 3: أي استراتيجية أنسب لموقع ويب يُنشَر عدة مرات في اليوم؟

a) Git Flow

b) GitHub Flow أو Trunk-Based

c) بلا فروع أصلاً

d) فرع لكل سنة

السؤال 4: في Trunk-Based Development، كيف نخفي ميزة غير منتهية؟

a) في فرع طويل لعدة أسابيع

b) بـ feature flag (علم ميزة)

c) بحذف الشفرة كل مساء

d) لا يمكن، يجب إنهاء الكل دفعة واحدة

السؤال 5: أي بادئة فرع تُستخدم لتصحيح خطأ حرج مباشرة في الإنتاج؟

a) feature/

b) release/

c) hotfix/

d) develop/

المطلوب

تعمل على مستودع main فيه مستقر. طُلب منك إضافة صفحة «حول». طبّق GitHub Flow:

1. انطلق من main محدَّث.
2. أنشئ فرع ميزة حسن التسمية.
3. أودع إضافة الملف apropos.html.
4. ادفع الفرع نحو المستودع البعيد لتحضير طلب سحب.
5. اسرد فروعك للتحقق.

التصحيح

# 1. الانطلاق من main محدَّث
git switch main
git pull origin main

# 2. إنشاء فرع وصفي
git switch -c feature/page-apropos

# 3. إنشاء الملف ثم إيداعه
echo "<h1>حول</h1>" > apropos.html
git add apropos.html
git commit -m "إضافة صفحة حول"

# 4. دفع الفرع نحو البعيد
git push -u origin feature/page-apropos

# 5. التحقق من الفروع
git branch

النتيجة المتوقعة:

* feature/page-apropos
  main

الخطوة المنطقية التالية: فتح طلب سحب على GitHub لمراجعة هذا العمل ودمجه — هذا موضوع الدرس 03 بالضبط.

النقاط التي يجب تذكّرها

1. الفرع يعزل العمل دون التأثير على الشفرة المستقرة.
2. أنواع الفروع: main، develop، feature/، release/، hotfix/ — لكل منها دور.
3. Git Flow: منظَّم، فرعان دائمين، مثالي للإصدارات المخطَّطة.
4. GitHub Flow: بسيط، فرع main + طلبات سحب، مثالي للويب.
5. Trunk-Based: تكامل متكرر جداً على الجذع، يتطلّب CI صلباً.
6. الاختيار يعتمد على المنتج والفريق ووتيرة النشر.

ما يلي

الآن وقد عرفت تنظيم فروعك، حان الدرس 02 — الدمج وإعادة الأساس: كيف تجمع هذه الفروع بنظافة وتحل التعارضات.