استراتيجيات التفرع في Git: Git Flow وGitHub Flow وترنك-بازد

ماذا ستخرج به من هذا المقال؟

قرار التفرع ليس قرارًا تقنيًا ينتهي عند رسم السهام في المخطط، بل قرار اجتماعي يحدد كيف يتعاون الفريق، وكيف تُقرأ المراجعات، وكيف تُصدر الإصدارات، وكيف يتصرف المطور عند الخلاف. هذا المقال يقارن الاستراتيجيات الرئيسية — Git Flow، وGitHub Flow، وترنك-بازد (Trunk-Based) — ليس لتعلن فائزًا، بل لِتملّكك معايير الاختيار: حجم الفريق، ودورة الإصدار، ومتطلبات الدعم، ومستوى النضج في التطوير.

ستبني صورة صادقة عن كل نموذج: متى يمنحك التفرع الطويل أمان العزل ومتى يحوّل الدمج إلى أسبوع من الصراعات، ومتى يجعل ترنك-بازد الحركة سريعة ومتى يكسر الإنتاج. وأخيرًا ستحصل على قاعدة قرار عملية تختار بها النموذج الذي تناسب مرحلة فريقك لا النموذج الذي يبدو في منشور.

لماذا تختلف الاستراتيجيات فعلًا؟

كل استراتيجية تفرع هي في الحقيقة إجابة عن أربعة أسئلة متضاربة غالبًا:

• كم من الوقت يعيش الفرع قبل الدمج؟ جلسة واحدة أم أسبوعان.


• من يملك المسار إلى الإنتاج؟ الجميع دائمًا أم عدد محدد من المحافظين.


• كيف تصل الميزة إلى المستخدم؟ مباشرة بعد الانتهاء أم في موعد إصدار مجدول.


• كيف يدعم الإصدار القديم؟ بالتصحيح في مكانه أم بالرجوع أم بالانتظار.

لا توجد إجابة صحيحة مجردة؛ هناك إجابة صحيحة لمشروعك في هذه اللحظة. المشاريع التي تفشل في التفرع لا تفشل غالبًا لاختيارها النموذج «الخاطئ»، بل لتأرجحها بين النماذج دون قرار.

Git Flow: الحارس عندما تكون الإصدارات بندًا رسميًا

Git Flow يبني حول فرعين دائمين — main يُمثّل الحالة القابلة للإصدار وdevelop حيث يلتقي التطوير — وفروعًا مؤقتة للميزات والإصدارات والتصحيحات. القوة الحقيقية ليست في الفروع نفسها بل في الانضباط: كل ميزة تعيش في فرع خاص، وتصل إلى develop بالمراجعة، وتنتقل إلى release/* عند الاقتراب من الإصدار، وتُدمج في main مع وسم إصدار.

git flow init

git flow feature start payment-webhook     # feature/payment-webhook

git flow release start 2.4.0                # release/2.4.0

git flow hotfix start billing-regression    # hotfix/billing-regression

الثمن: طول عمر الفروع يتناسب مع طول القرارات. فرع ميزة ظل أسبوعين يدفعك عند الدمج إلى أزمة صراعات تلتهم يومًا كاملًا، وdevelop المؤجلة تبتعد عن main تدريجيًا حتى يصبح الدمج الأخير اختبارًا عاجلًا.

GitHub Flow: البساطة التي تُصدر بلا توقف

GitHub Flow يختصر البنية إلى قاعدة واحدة: كل التغييرات تذهب إلى main بلا فروع وسيطة. الميزة في فرع صغير يُدمج فور اكتمالها بالمراجعة، وفي أي لحظة على main قابلة للنشر. المفتاح ليس عدم وجود فرع develop، بل أن الفاصل الوحيد بين الشيفرة والمستخدم هو المراجعة والاختبارات لا مرحلة تجميع.

• اجعل الفروع صغيرة: ½-1 يوم عمل، فإن كبرت انكسرت الفكرة.


• اربط PR بالحالة: أخفِ التغييرات خلف خصائص (feature flags) إن أمكن.


• المسار إلى الإنتاج واحد: ما الذي دخل main أصبح قابلًا للنشر فورًا.

git checkout -b feat/invoice-download

# ... اتعب ثم ينشر

git push -u origin feat/invoice-download

# مراجعة → دمج → نشر تلقائي من main

ترنك-بازد: النشر المستمر على حافة الاحتواء

ترنك-بازد يقصّر كل الفروع لاجتياز قصير: يدمج الجميع على main عدة مرات يوميًا، وتصبح القابلية للنشر خاصية دائمة لا حدثًا. لا فرع ميزة محمي طويلًا؛ عزل الميزة يتحقق بأعلام الخصائص (feature flags) التي تُخفي كودًا غير مكتمل خلف مفتاح تشغيل، لا بأفرع تعزل الكود جسديًا.

الأهلية تتطلب بنية تحتية ناضجة: اختبارات تحمي main، ونشر تلقائي، وقدرة فريق على تقسيم العمل لشرائح صغيرة. بدونها يتحول النموذج إلى فوضى يفشل فيها أي دمج اعتمادًا على من وصل أولًا.

مقارنة القرارات عبر النماذج الثلاثة

اختيارك ليس أبديًا

الفرق تنتقل بين النماذج كما تنتقل مشاريعها. ابدأ بترنك-بازد إن كان الإنتاج قادرًا على الاستجابة اليومية، أو بـ GitHub Flow إن كانت مراجعتك سليمة، واختر Git Flow فقط حين تثبت متطلبات إصدار رسمي الحاجة فعلًا. المهم أن يكون القرار صريحًا لدى الفريق كله، موثّقًا، ومثبتًا بقواعد الحماية (branch protection) لا بالعادات الشفوية.

قائمة تحقق تطبيق النموذج

• قرار التفرع موثق ومفهومًا لكل أعضاء الفريق.


• قواعد حماية على main: دمج مطلوب، مراجعة إلزامية، فورماتة موحدة.


• فروع الميزات صغيرة وقصيرة العمر (يوم كحد أقصى إن أمكن).


• خط الأنابيب يعصم main: اختبارات قبل الدمج لا بعده.


• مسار الأصدارات محدد (إصدار رسمي أم نشر مستمر) بلا غموض.


• أعلام الخصائص جاهزة إن اخترت إخفاء ميزة غير مكتملة.

الأسئلة الشائعة

هل يمكن مزج النماذج؟

نعم لنماذج صريحة: بعض المشاريع تستخدم ترنك-بازد للخدمات الداخلية و Git Flow لخدمة عميل بإصدارات ملتزمة. الممنوع هو التذبذب غير المعلن داخل مصدر واحد.

متى أصبح أفرع الإصدارات مطلوبة؟

عندما يُطلب دعمٌ لإصدار سابق بعد إصدار نسخة لاحقة، أو عندما تلتزم بعقد مع عميل ببنية إصدار معتمدة. دون هذا الالتزام يبقى main النشر المستمر كافيًا.

هل حماية main تشمل المديرين؟

الأفضل ألا تُعطَ استثناءات: حاجز أمني يُخرق بالعادة يتحول إلى ديكور. جرّب استثناء النسخ الاكتفاء بالإغلاق البديل متى رُفضت الحماية.

الخلاصة

الخطوة التالية

بعد أن حددت شكل الفروع، تحتاج من يُدافع عن main: مراجعات صارمة وخط أنابيب يمنع وصول شيفرة مكسورة. المقال القادم يبني GitHub Actions من الصفر ويحوّل كل قرارك إلى آلية تُنفَّذ تلقائيًا.

flowchart LR

    A["إيداع الشيفرة"]

    B["اختبارات آلية"]

    C["بناء نسخة"]

    D["نشر متدرج"]

    E["مراقبة وتراجع"]

    A --> B

    B --> C

    C --> D

    D --> E