Git Flow: ما هو، نموذج التفرع واستخدامه في المشاريع

ما هو Git Flow؟

Git Flow هو نموذج تفرع Git يحدد هيكلاً صارمًا للفروع وقواعد الدمج لإدارة التطوير والإصدارات والإصلاحات. نشر Vincent Driessen مقال «A successful Git branching model» في يناير 2010، ومنذ ذلك اصبح Git Flow معيارًا دي فاكتو في تطوير Java و .NET المؤسسي. الفكرة الرئيسية هي تقسيم الكود إلى خمسة أنواع فروع بمستويات استقرار مختلفة.

وفقًا لـ Atlassian Git Tutorials، 2024، يعتمد Git Flow على فرعين دائمين: main (سابقًا master) و develop. جميع الفروع الأخرى مؤقتة: feature، release، hotfix. كل نوع فرع له دورة حياة وقواعد دمج محددة بوضوح. في تطوير التطبيقات المحمولة، يستخدم Git Flow في المشاريع ذات دورات الإصدار المنتظمة (2–4 أسابيع) ودعم إصدارات متعددة.

Git Flow يختلف عن النماذج البسيطة (GitHub Flow) بحاجته إلى فرع develop منفصل للتكامل. يضيف هذا خطوة واحدة إلى عملية الدمج، ولكنه يوفر عزلاً إضافيًا للميزات غير المكتملة عن الكود الجاهز للإصدار.

Vincent Driessen وتاريخ Git Flow

في عام 2010، نشر Vincent Driessen المقال «A successful Git branching model»، الذي أصبح واحدًا من الأكثر استشهادًا في تاريخ Git. تم إنشاء النموذج لمشروع بإصدارات ثابتة ودعم متوازٍ للإصدارات. في عام 2020، أعترف Driessen أن Git Flow قديم بالنسبة لممارسات CI/CD الحديثة، ولكن النموذج يظل ذا صلة للمشاريع ذات دورات الإصدار الطويلة والحاجة لدعم الإصدارات القديمة.

# تهيئة Git Flow
git flow init

# إنشاء فرع feature
git flow feature start "add-auth"

# إنهاء فرع feature (الدمج في develop)
git flow feature finish "add-auth"

# إنشاء release
git flow release start "1.2.0"
git flow release finish "1.2.0"

فرع Main: كود الإصدار والوسم

Main (سابقًا master) هو الفرع الرئيسي الذي يحتوي فقط على كود الإصدار الجاهز للنشر. كل commit في main يجب أن يقابل إصدارًا محددًا للمنتج، موسومًا بتوقيع بتنسيق الإصدار الدلالي، مثل v1.0.0، v1.1.0. لا يتم تنفيذ أي تطوير مباشر في main — تصل التغييرات هنا فقط عبر فروع release أو hotfix.

وفقًا لـ semver.org، 2024، تستخدم العلامات في main تنسيق MAJOR.MINOR.PATCH. يزداد MAJOR مع التغييرات غير المتوافقة في API، و MINOR عند إضافة وظائف متوافقة مع الإصدارات السابقة، و PATCH عند إصلاح الأخطاء. في Git Flow، كل إنهاء release ينشئ تلقائيًا commit في main مع وسم إصدار.

فرع Main هو الفريد الذي ينشر في الإنتاج. للمشاريع المحمولة، هذا يعني أن الدفع إلى main ينشط خط أنابيب بناء App Bundle أو IPA والنشر في Google Play / App Store. في إعدادات CI/CD لـ GitLab، main محمي من force-push والحذف.

الإصدار الدلالي والعلامات

كل commit في main يرافقه وسم بتنسيق SemVer: vMAJOR.MINOR.PATCH. MAJOR — للتغييرات غير المتوافقة في API، MINOR — لوظائف جديدة متوافقة مع الإصدارات السابقة، PATCH — لإصلاح الأخطاء. مثال: v2.1.0 يعني الإصدار الرئيسي الثاني بميزات جديدة ودون إصلاحات. في Git Flow، تنشأ العلامات تلقائيًا عند إنهاء release أو hotfix من خلال الأمر git flow release finish.

فرع Develop: خط التكامل التطويري

Develop هو الفرع الدائم الثاني في Git Flow، المصمم لدمج جميع الميزات المكتملة. يدمج المطورون فروع feature في develop بعد اجتياز مراجعة الكود وفحوصات CI/CD. يحتوي develop على أحدث نسخة مستقرة من الكود، متضمنة جميع الميزات المنفذة للسبرينت الحالي.

وفقًا لـ DataSift Git Flow Guide، 2024، قد يكون develop غير مستقر مؤقتًا بسبب التكاملات الجارية. لمنع المشاكل، تمارس الفرق التكامل المستمر (CI): كل ميزة تجب أن تجتاز مجموعة كاملة من الاختبارات قبل الدمج في develop. إذا فشلت CI، يصلح المطور الكود قبل الدمج التالي. Develop دائمًا مرتبط بالنسخة الحالية لـ main: مباشرة بعد الإصدار، يتم مزامنة develop مع main عبر الدمج.

فروع Feature: تطوير وظائف جديدة

فروع Feature — فروع مؤقتة لتطوير ميزات فردية أو إصلاح الأخطاء أو التجارب. يتم إنشاء كل فرع feature من develop وبعد الاكتمال يدمج عودة إلى develop. عادة ما يحتوي اسم فرع feature على رقم المهمة أو وصفًا مختصرًا: feature/APP-123-add-oauth، feature/redesign-profile. في Git Flow، يمكن لفروع feature أن توجد لفترة غير محدودة.

وفقًا لـ Pro Git Book، 2024، فروع feature هي بيئة تطوير معزولة: التغييرات في فرع واحد لا تؤثر على الأخرى حتى الدمج. في المشاريع المحمولة، تتم مزامنة فروع feature مع develop عبر rebase أو merge لتجنب التعارضات الكبيرة عند الإنهاء. يوصى بإجراء rebase لفرع feature على develop قبل إنشاء MR.

# إنشاء فرع feature يدويًا (بدون git flow)
git checkout -b feature/APP-142-add-auth develop
git commit -m "Add OAuth2 authentication with Google"
git push origin feature/APP-142-add-auth

# إنشاء MR في GitLab عبر CLI
glab mr create \
    --source-branch "feature/APP-142-add-auth" \
    --target-branch "develop" \
    --title "Add OAuth2 authentication"

فروع Release: تحضير الإصدار

فروع Release — فروع مؤقتة تنشأ من develop لتحضير إصدار. عندما يحتوي develop على مجموعة كافية من الميزات لنسخة جديدة، ينشئ الفريق فرع release/X.Y.Z (على سبيل المثال release/2.1.0). في هذا الفرع تجرى فقط التعديلات النهائية: زيادة الإصدار، تحديث الترجمة، الاختبارات النهائية، إصلاح الأخطاء الحرجة.

وفقًا لـ Atlassian Git Tutorials، 2024، يحل فرع release مشكلة رئيسية: عزل التغييرات النهائية عن التطوير المتوازي. أثناء تحضير الإصدار، تستمر الميزات الجديدة للإصدار التالي في الاندماج في develop. بعد الاكتمال، يدمج فرع release في main (بوسم) وفي develop (لمزامنة زيادة الإصدار).

فروع Hotfix: إصلاحات عاجلة في الإنتاج

فروع Hotfix — فروع مؤقتة لإصلاح الأخطاء الحرجة بشكل عاجل في الإنتاج. نوع الفرع الوحيد في Git Flow الذي ينشأ من main لا من develop. تنسيق الاسم: hotfix/X.Y.Z+1 (على سبيل المثال hotfix/2.1.1). بعد الاكتمال، يدمج فرع hotfix في كل من main (كإصدار تصحيحي جديد) و develop (لضمان عدم فقدان الإصلاح في الإصدارات المستقبلية).

وفقًا لـ DataSift Git Flow Guide، 2024، يجب أن تكون فروع hotfix أقصر ما يمكن — فقط الإصلاح والاختبار. لا يجب أن يتضمن hotfix ميزات جديدة أو إعادة هيكلة. في تطوير التطبيقات المحمولة، تستخدم hotfix لإصلاح الأعطال الحرجة (معدل التعطل > 0.1%)، ثغرات الأمان أو الأخطاء المانعة في App Store.

مزايا وعيوب Git Flow لتطوير التطبيقات المحمولة

Git Flow يوفر هيكلاً واضحًا مفيدًا خاصة للفرق الكبيرة والمشاريع ذات الإصدارات المنتظمة. المزايا: عزل الميزات غير المكتملة في فروع feature، إمكانية تحضير الإصدار دون حجز التطوير، دعم إصدارات متعددة عبر hotfix. العيوب: التعقيد للمبتدئين، الحاجة إلى rebase منتظم لفروع feature، التعارضات مع الفروع طويلة العمر.

وفقًا لـ Martin Fowler، 2024، أهم عيب في Git Flow هو فروع feature طويلة العمر. إذا تم تطوير ميزة لمدة أسبوعين أكثر دون مزامنة مع develop، يصبح تعارض الدمج كبيرًا. للمشاريع المحمولة، يوصى بمزامنة فرع feature يوميًا عبر rebase على develop.

Git Flow لا يوصى به للمشاريع ذات النشر المستمر (كل commit في main → إنتاج). لمثل هذه المشاريع، يوفر GitHub Flow أو Trunk-Based Development نموذجًا أبسط وأسرع. ولكن للمشاريع ذات دورات الإصدار ودعم الإصدارات القديمة، يظل Git Flow الخيار الأمثل.

متى يضر Git Flow بالفريق

يصبح Git Flow مشكلة في ثلاث حالات: الفرق أقل من 5 أشخاص (تعقيد غير ضروري)، النشر المستمر (تأخير التسليم)، عدم انضباط rebase (تُنشئ فروع feature طويلة العمر تعارضات دمج). إذا كان الفريق يقضي أكثر من 20% من الوقت في دمج الفروع وحل التعارضات — فإن Git Flow غير مناسب لذلك الفريق حتى لو كان كبيرًا.

بدائل Git Flow: GitHub Flow و Trunk-Based Development

بدائل Git Flow تقدم عملية أبسط للفرق التي تمارس CI/CD. GitHub Flow يستخدم فرعًا واحدًا دائمًا (main) وفروع feature. تنشأ كل ميزة من main، وبعد المراجعة و CI تدمج عودة إلى main وتنشر فورًا. GitHub Flow أبسط ولكنه لا يدعم عزل الميزات غير المكتملة أو التحضير المتوازي للإصدار.

وفقًا لـ GitHub Docs، 2024، يذهب Trunk-Based Development (TBD) إلى أبعد: يعمل جميع المطورين في فرع واحد (trunk)، مستخدمين فروع feature قصيرة العمر (يومان). تتحكم feature toggles في رؤية الكود غير المكتمل. يتطلب TBD انضباطًا عاليًا في CI/CD وأتمتة الاختبار.

• GitHub Flow — main واحد + فروع feature، مثالي لـ CI/CD والفرق الصغيرة
• GitLab Flow — يوسع Git Flow بفروع البيئة (staging، production)
• Trunk-Based Development — فرع واحد + feature toggles، أقصى CI/CD، أدنى دمج
• One Flow — Git Flow مبسط دون فرع develop، main + feature + release فقط