Feature Branch في Git: ما هي، كيفية إنشاء والعمل مع الفروع

ما هو Feature Branch في Git

Feature Branch (فرع الميزة) هو فرع مؤقت في Git يتم إنشاؤه من develop لتطوير وظيفة معينة. على عكس الفروع طويلة العمر main و develop، توجد فروع feature لفترة محدودة — من بضع ساعات إلى بضعة أسابيع.

الهدف الرئيسي من feature branch هو عزل التغييرات المرتبطة بمهمة واحدة عن باقي الكود. يمكن للمطور التجربة وإجراء العديد من commits وحتى كسر الكود في فرعه الخاص دون التأثير على عمل أعضاء الفريق الآخرين.

بعد اكتمال التطوير، يتم دمج feature branch مرة أخرى في develop عبر Pull Request مع مراجعة إلزامية للكود. بعد الدمج، يتم حذف الفرع عادةً للحفاظ على نظافة المستودع.

وفقًا لـ Vincent Driessen، 2010، أصبح نموذج Git Flow مع فروع feature معيارًا صناعيًا بفضل الفصل الواضح للمسؤوليات بين أنواع الفروع المختلفة.

سير العمل مع Feature Branch

سير العمل مع feature branch يتكون من سلسلة من الخطوات التي يقوم بها المطور لكل ميزة جديدة. هذه العملية تقلل من تعارضات الدمج وتضمن مراقبة جودة الكود.

1. إنشاء الفرع من أحدث commit في develop. ينتقل المطور إلى develop ويحدّثه وينشئ فرع feature جديد.
2. التطوير والـ commits في فرع feature. يقوم المطور بإجراء التغييرات، ويصنع commits بأوصاف واضحة، ويدفع الفرع بشكل دوري إلى المستودع البعيد.
3. المزامنة مع develop — أثناء التطوير، قد يتقدم الفرع الرئيسي. يقوم المطور بإجراء rebase أو merge من develop إلى فرع feature الخاص به.
4. إنشاء Pull Request — عندما تكون الميزة جاهزة، يفتح المطور PR لمراجعة الكود. يراجع الفريق الكود ويترك تعليقات.
5. الدمج والحذف — بعد الموافقة على PR، يتم دمج الفرع في develop وحذفه محليًا وعن بُعد.

المزامنة الدورية مع develop مهمة جدًا. كلما عاش فرع feature لفترة أطول دون دمج تغييرات من develop، زاد احتمال حدوث تعارضات في الدمج النهائي.

وتيرة مزامنة فرع feature

قواعد تسمية فروع feature

تسمية الفروع هي جزء مهم من انضباط الفريق. معيار تسمية موحد يسمح بتحديد سريع للمهمة التي يتم العمل عليها ومن يقوم بها.

• feature/الاسم — البادئة feature/ تُستخدم في Git Flow الكلاسيكي. مثال: feature/added-auth-module.
• feature/JIRA-123-الوصف — الربط برقم المهمة في نظام التتبع. مثال: feature/PROJ-42-add-login.
• feature/النوع/الاسم — تنسيق موسع مع تحديد نوع المهمة. مثال: feature/feat/analytics-dashboard.

استخدام معرّف المهمة من JIRA أو Trello أو نظام آخر هو أفضل ممارسة. فهو يربط الكود تلقائيًا بالمهمة ويبسط البحث عن الفروع عبر git log.

عملية Pull Request

Pull Request (أو Merge Request في GitLab) هو طلب لدمج فرع feature في develop. PR ليس مجرد عملية تقنية، بل هو عملية مراجعة كود جماعية ترفع جودة الكود وتنشر المعرفة داخل الفريق.

يحتوي PR الجيد على عنوان بوصف مختصر للمهمة، رابط للتذكرة ووصف للتغييرات. يجب على المطور توضيح ما تم فعله بالضبط، وما هي الملفات التي تم تغييرها وما إذا كانت هناك مخاطر محتملة لأجزاء أخرى من المشروع.

يراجع الفريق الكود في PR، ويترك تعليقات، ويطلب تغييرات (change requests) ويوافق على الدمج (approve). بعد الموافقة، يتم تنفيذ merge أو squash merge.

متوسط وقت مراجعة PR في تطوير التطبيقات المحمولة يتراوح من 4 إلى 24 ساعة. مكتبة Danger تؤتمت جزءًا من الفحوصات، بتشغيل linters واختبارات مباشرة في PR.

توصيات لإنشاء PR جيد

• الحجم — لا يزيد عن 300-400 سطر من التغييرات. PRs الكبيرة يصعب مراجعتها، وجودة المراجعة تنخفض.
• PR واحد — مهمة واحدة — تجنب خلط تغييرات غير مرتبطة في طلب واحد.
• لقطات الشاشة — لتغييرات واجهة المستخدم، أرفق لقطات قبل وبعد.
• الاختبارات — للوظائف الجديدة، اكتب اختبارات الوحدة وأدرجها في PR.

استراتيجيات دمج فروع feature

بعد الموافقة على PR، يمكن دمج فرع feature في develop بطرق مختلفة. يؤثر اختيار استراتيجية الدمج على تاريخ commits وإمكانية التراجع عن التغييرات.

• Merge commit — ينشئ commit دمج، محتفظًا بكل تاريخ commits لفرع feature. يبقى التاريخ كاملاً، لكن رسم التفرع يصبح أكثر تعقيدًا.
• Squash merge — يدمج كل commits فرع feature في commit واحد ويضيفه فوق develop. يصبح التاريخ أنظف، لكن المعلومات عن commits الوسيطة تُفقد.
• Rebase and merge — يعيد كتابة commits فرع feature فوق آخر commit في develop ويدمج دون commit إضافي. يبقى التاريخ خطيًا.

للمشاريع المحمولة ذات الإصدارات المتكررة، يُستخدم squash merge في الغالب: فهو يعطي تاريخًا نظيفًا في develop، بينما تبقى تفاصيل التطوير في وصف PR ومهمة tracker.

الأخطاء النموذجية عند العمل مع Feature Branch

حتى المطورون ذوو الخبرة يرتكبون أخطاء عند العمل مع فروع feature. معرفة المشكلات النموذجية تساعد في تجنب إضاعة الوقت والبيانات.

• عمر الفرع طويل جدًا — فرع feature يعيش أكثر من 2-3 أسابيع دون مزامنة مع develop، مما يؤدي إلى تعارضات دمج ضخمة.
• Committs بأوصاف غير واضحة — رسائل مثل «fix» أو «update» لا توضح ما تم تغييره ولماذا.
• خلط المهام — في نفس فرع feature يتم تطوير وظيفتين غير مرتبطتين، مما يجعل التراجع الانتقائي مستحيلاً.
• غياب المزامنة — المطور لا يقوم بـ git fetch ولا يحدّث develop، مما يسبب تعارضات عند الدمج النهائي.

أفضل طريقة لتجنب هذه المشكلات هي الاتفاق على قواعد العمل في بداية المشروع واستخدام الفحوصات الآلية في خط أنابيب CI/CD.

أمثلة على الأوامر للعمل مع Feature Branch

لننظر في سيناريو عملي: مطور يبدأ ميزة مصادقة جديدة في تطبيق محمول. ينشئ فرع feature، يعمل على الكود ويكمل المهمة بـ Pull Request.

# تحديث develop وإنشاء فرع feature
git checkout develop
git pull origin develop
git checkout -b feature/add-login-screen

# العمل على الميزة: commits
git add src/ui/login/
git commit -m "Add login screen layout"

# دفع فرع feature إلى الخادم البعيد
git push origin feature/add-login-screen

# المزامنة مع develop (rebase)
git fetch origin develop
git rebase origin/develop

# بعد الموافقة على PR: تحديث develop المحلي وحذف الفرع
git checkout develop
git pull origin develop
git branch -d feature/add-login-screen

الأمر git branch -d يحذف الفرع فقط بعد دمج تغييراته بالكامل. إذا لم يُدمج الفرع، سيقترح Git استخدام git branch -D للحذف الإجباري — استخدم هذا العلم بحذر.

أتمتة الفحوصات في فرع feature

يجب تشغيل خط أنابيب CI/CD لكل فرع feature قبل إنشاء PR. هذا يسمح باكتشاف المشكلات في مرحلة مبكرة، قبل أن يصل الكود لمراجعة مطورين آخرين.

# GitHub Actions لفحص فرع feature
name: Feature Branch CI

on:
  push:
    branches:
      - 'feature/**'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test
      - name: Lint check
        run: ./gradlew lint

يتحقق خط الأنابيب من أن الكود يترجم، والاختبارات تمر، وأسلوب الكود يتوافق مع معايير الفريق. فقط بعد اجتياز جميع الفحوصات يمكن إنشاء Pull Request.