الفرع الرئيسي Main و Master في Git: ما هو ولماذا تحتاج إلى الفرع الرئيسي

ما هو Main / Master Branch في Git

الفرع الرئيسي Main (أو Master — حسب إعدادات المستودع) هو الفرع الافتراضي الذي يتم إنشاؤه عند تهيئة أي مستودع Git. إنه الفرع الرئيسي للمشروع ويحتوي على كود جاهز للنشر في الإنتاج.

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

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

وفقاً لـ Git Book، main ليس فرعاً خاصاً بخصائص فريدة، بل هو مرجع عادي لـ commit يُعتبر رئيسياً بالاتفاق. Git لا يميز بين main وأي فرع آخر على مستوى النظام.

الانتقال من master إلى main

تاريخياً، كان الفرع الافتراضي في Git يُسمى master. في يونيو 2020، لفتت حركة Black Lives Matter الانتباه إلى مصطلحي master و slave في صناعة تكنولوجيا المعلومات. أعلنت GitHub عن الانتقال إلى مصطلح main للفرع الافتراضي.

منذ أكتوبر 2020، جميع المستودعات الجديدة على GitHub تُنشأ بالفرع main. GitLab و Bitbucket أيضاً طبقا دعم main كاسم افتراضي. Git 2.28 (يوليو 2020) أضاف الخيار init.defaultBranch لتكوين اسم الفرع الافتراضي.

تقنياً، إعادة تسمية فرع موجود من master إلى main هي عملية بسيطة. التحدي الرئيسي هو تحديث جميع المراجع في تكوينات CI/CD والوثائق والمستودعات المحلية للمطورين.

لإعادة تسمية فرع في مستودع موجود، نفذ:

# إعادة تسمية master محلياً إلى main
git branch -m master main

# تحديث المستودع البعيد
git push -u origin main

# حذف master القديم على الخادم
git push origin --delete master

# تحديث HEAD على الخادم
# (عبر واجهة GitHub: Settings ← Branches ← Default branch)

دور main في Git Flow و GitHub Flow

Git Flow و GitHub Flow يحددان دور الفرع main بشكل مختلف. اختيار النموذج يعتمد على حجم الفريق، وتكرار الإصدارات، ومتطلبات استقرار الكود.

لتطوير التطبيقات المحمولة، Git Flow هو المعيار، حيث أن نشر تطبيق في App Store و Google Play له دورات إصدار ثابتة. GitHub Flow أكثر ملاءمة لمشاريع الويب التي يمكن نشرها عدة مرات يومياً.

GitHub Flow — نهج مبسط

في GitHub Flow، لا يوجد فرع develop. جميع فروع feature تُنشأ مباشرة من main، وبعد الانتهاء تُدمج مرة أخرى عبر Pull Request. كل دمج في main يُشغل تلقائياً النشر إلى الإنتاج. هذا النموذج يتطلب مستوى عالياً من أتمتة الاختبارات وانضباط الفريق.

في GitHub Flow، لا يوجد فرع develop. جميع فروع feature تُنشأ مباشرة من main، وبعد الانتهاء تُدمج مرة أخرى عبر Pull Request. كل دمج في main يُشغل تلقائياً النشر إلى الإنتاج. هذا النموذج يتطلب مستوى عالياً من أتمتة الاختبارات وانضباط الفريق.

حماية الفرع main

حماية الفرع لـ main هي إعداد إلزامي في أي مشروع تجاري. بدونها، قد يؤدي دفع عرضي إلى إرسال كود غير مكتمل إلى الإنتاج أو كسر تطبيق يعمل لجميع المستخدمين.

• يتطلب pull request — الدفع المباشر إلى main محظور. جميع التغييرات عبر PR مع مراجعة.
• يتطلب الموافقات — حد أدنى موافقتين للدمج في main (في حال فات أحد المراجعين شيئاً).
• يتطلب فحوصات الحالة — جميع فحوصات CI/CD يجب أن تنجح قبل الدمج.
• يتطلب التحديث — يجب أن يستند PR إلى آخر commit في main.
• يشمل المسؤولين — الحماية تنطبق حتى على مالكي المستودع.
• يتطلب commits موقعة — جميع commits في main يجب أن تكون موقعة بمفتاح GPG.

تكوين جميع القواعد الست هو المعيار للمشاريع المحمولة التي تضم 10,000+ مستخدم. للمشاريع الصغيرة، القواعد الثلاث الأولى كافية.

مقارنة مستويات الحماية لأنواع المشاريع المختلفة

مستوى حماية main يعتمد على حجم المشروع. يمكن لشركة ناشئة الاكتفاء بالحد الأدنى من الحماية، بينما يتطلب تطبيق المؤسسات أقصى القيود.

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

الوسم هو ممارسة إنشاء مراجع مسماة لـ commits محددة في main. كل علامة تقابل إصداراً من التطبيق تم نشره في الإنتاج. هذا يسمح بالتبديل السريع إلى أي إصدار سابق للتصحيح أو الإصلاح.

معيار تسمية العلامات في تطوير التطبيقات المحمولة هو SemVer (الإصدار الدلالي): v1.2.3، حيث الرقم الأول هو الإصدار الرئيسي (تغييرات جذرية)، والثاني هو الإصدار الثانوي (ميزات جديدة)، والثالث هو التصحيح (إصلاحات).

يتم إنشاء العلامة بعد دمج فرع release في main. ثم يتم بناء هذا commit في CI/CD، وتوقيعه، وإرساله إلى متجر التطبيقات. إذا تم اكتشاف خطأ في العلامة، يتم إنشاء فرع hotfix من تلك العلامة.

# إنشاء علامة إصدار مشروحة
git tag -a v2.4.1 -m "Release version 2.4.1"

# إرسال العلامة إلى الخادم
git push origin v2.4.1

# عرض جميع العلامات في المستودع
git tag -l "v2.*"

# إنشاء فرع hotfix من علامة محددة
git checkout -b hotfix/crash-fix v2.4.1

تسلسل فروع Git Flow

فهم تسلسل الفروع في Git Flow هو الأساس لتنظيم التطوير التعاوني بشكل صحيح. كل نوع فرع له مصدره وغرضه وقواعد الدمج الخاصة به.

• Main (المستوى 1) — الفرع الجذري، يحتوي فقط على إصدارات. يُنشأ عند تهيئة المستودع.
• Develop (المستوى 2) — يُنشأ من main عند بدء المشروع. يحتوي على كود تكامل جميع الميزات.
• Feature (المستوى 3) — يُنشأ من develop. تطوير معزول لميزات فردية.
• Release (المستوى 2) — يُنشأ من develop. تحضير إصدار معين للنشر.
• Hotfix (المستوى 2) — يُنشأ من main. إصلاحات عاجلة لأخطاء الإنتاج الحرجة.

قاعدة مهمة: feature لا يُدمج أبداً مباشرة في main. feature → develop → release → main هي سلسلة الدمج الصحيحة. انتهاك هذه القاعدة يبطل الغرض من نموذج Git Flow بأكمله.

أمثلة أوامر للعمل مع main

لنفترض سيناريو: أكمل الفريق تحضير الإصدار v2.5.0. فرع release تمت مراجعته وجاهز للدمج في main. بعد الدمج، يتم إنشاء علامة ونشر الإصدار.

# التبديل إلى main والتحديث
git checkout main
git pull origin main

# دمج فرع release المُتحقق منه
git merge --no-ff release/2.5.0

# إنشاء علامة إصدار
git tag -a v2.5.0 -m "Release 2.5.0 - Payment integration"

# إرسال main والعلامة إلى الخادم
git push origin main --tags

العلم --no-ff (بدون تقدم سريع) يضمن إنشاء commit دمج، حتى لو كان يمكن إجراء الدمج ببساطة بتحريك المؤشر. هذا يحتفظ بمعلومة أن التغييرات جاءت من فرع release، مما يسهل تحليل التاريخ.

العمل مع hotfix عبر main

إذا تم اكتشاف خطأ حرج في الإنتاج، تختلف العملية عن الإصدار العادي. يتم إنشاء hotfix من main، وبعد الإصلاح، يُدمج في كل من main و develop.

إذا تم اكتشاف خطأ حرج في الإنتاج، تختلف العملية عن الإصدار العادي. يتم إنشاء hotfix من main، وبعد الإصلاح، يُدمج في كل من main و develop.

# إنشاء فرع hotfix من main
git checkout main
git checkout -b hotfix/2.5.1-crash-fix

# الإصلاح والcommit
git add src/fix/
git commit -m "Fix crash on login screen"

# دمج hotfix مرة أخرى إلى main
git checkout main
git merge --no-ff hotfix/2.5.1-crash-fix
git tag -a v2.5.1 -m "Hotfix 2.5.1"
git push origin main --tags

# دمج hotfix أيضاً في develop
git checkout develop
git merge --no-ff hotfix/2.5.1-crash-fix
git push origin develop

# حذف فرع hotfix
git branch -d hotfix/2.5.1-crash-fix