Git والتحكم في الإصدارات في تطوير تطبيقات الجوال: ما هو، الأوامر الأساسية وكيف يعمل

التحكم في الإصدارات وGit: ما هو؟

Git هو نظام تحكم في الإصدارات موزع (VCS) أنشأه لينوس تورفالدس في 2005 لتطوير نواة لينكس. على عكس الأنظمة المركزية (SVN، CVS)، يخزن Git نسخة كاملة من تاريخ المشروع على كل كمبيوتر للمطور. هذا يعني أنه يمكنك عمل commits وتصفح التاريخ وإنشاء فروع حتى بدون اتصال بالإنترنت.

يعمل Git باستخدام اللقطات (snapshots) — كل commit يحفظ حالة جميع ملفات المشروع في وقت الحفظ. إذا لم يتغير ملف، ينشئ Git مرجعًا للإصدار السابق، مما يوفر المساحة. وفقًا لتحليل GitHub (2025)، يحتوي المستودع العادي على 1200 commit و15 فرعًا.

في IT Sectr، نستخدم Git منذ 2017 في جميع المشاريع. تظهر تجربتنا أن الإعداد الصحيح لـ Git من اليوم الأول يوفر للفريق ما يصل إلى 30% من الوقت في الدمج وحل النزاعات. أصبح Git المعيار الفعلي — فهو مدعوم من جميع بيئات التطوير المتكاملة الحديثة (Android Studio، Xcode، VS Code) وأنظمة CI/CD.

# الإعداد الأساسي لـ Git
git config --global user.name "اسمك"
git config --global user.email "your@email.com"

# إنشاء مستودع جديد
git init my-project
cd my-project

# إضافة الملفات وعمل commit
git add README.md
git commit -m "Initial commit"

# العمل مع مستودع بعيد
git remote add origin https://github.com/user/my-project.git
git push -u origin main

يظهر الكود أعلاه التسلسل الأساسي: تهيئة مستودع، أول commit، والنشر على خادم بعيد. الأمر git init ينشئ مجلد .git مخفيًا سيخزن كل تاريخ المشروع. كل git commit ينشئ نقطة استعادة يمكنك العودة إليها في أي وقت.

المفاهيم الأساسية: Repository، Branch، Commit

فهم المفاهيم الثلاثة الأساسية — Repository، Branch، Commit — ضروري للعمل مع أي نظام تحكم في الإصدارات. المستودع هو حاوية للمشروع بأكمله. Commit هو حالة محفوظة للملفات. Branch هو خط تطوير منفصل.

Repository (المستودع) يمكن أن يكون محليًا (على جهاز الكمبيوتر الخاص بك) أو بعيدًا (على خادم GitHub، GitLab). كل مطور يستنسخ المستودع البعيد إلى جهازه ويعمل مع نسخة محلية. تتم مزامنة التغييرات عبر push (إرسال) و pull (سحب). في التحكم في الإصدارات الموزع، يخزن كل مطور نسخة كاملة من التاريخ.

Branch (الفرع) هو مؤشر لأحد commits. تسمح الفروع بالتطوير المتوازي: مطور يعمل على ميزة جديدة (feature branch)، وآخر يصلح خطأ (hotfix branch)، وثالث يعد إصدارًا (release branch). وفقًا لـ GitLab Flow (2025)، المشروع العادي لديه 3–5 فروع نشطة في وقت واحد.

Commit هو وحدة تغيير. كل commit يحتوي على تجزئة فريدة (SHA-1)، ورسالة، ومؤلف، وطابع زمني. الممارسة الجيدة هي عمل commits صغيرة وذات معنى مع رسائل وصفية — هذا يبسط مراجعة الكود والتراجع. التحكم في الإصدارات عبر commits يمنحك تاريخ المشروع الكامل.

Feature Branch

Feature Branch (فرع الميزة) هو فرع مؤقت يتم إنشاؤه من develop أو main لتطوير مهمة محددة. بعد الانتهاء من العمل، يتم دمج الفرع مرة أخرى عبر Pull Request وحذفه. هذه الممارسة تسمح بعزل التغييرات دون التأثير على استقرار قاعدة الكود الرئيسية.

سير العمل النموذجي: إنشاء فرع feature/add-login → عمل عدة commits → إنشاء Pull Request → المرور بمراجعة الكود → الدمج في develop. في IT Sectr نستخدم هذا النهج تمامًا: كل مهمة في Jira تقابل فرع ميزة منفصل. هذا يبسط تتبع التغييرات والتراجع إذا لزم الأمر.

Rebase ضد Merge

Merge ينشئ commit دمج يجمع بين فرعين. يحافظ على التاريخ الكامل، بما في ذلك خطوط التطوير المتوازية. Rebase يعيد كتابة التاريخ: يأخذ commits من فرع و"يعيد تطبيقها" فوق فرع آخر، منشئًا تاريخًا خطيًا.

Merge أفضل للفروع العامة والفرق الكبيرة حيث يكون التسلسل الزمني مهمًا. Rebase مناسب لفروع الميزات الشخصية قبل إنشاء PR — يجعل التاريخ أنظف وأكثر قابلية للفهم. ومع ذلك، لا ينبغي أبدًا تطبيق rebase على الفروع التي يعمل عليها مطورون آخرون، لأنه يعيد كتابة التاريخ.

# إنشاء والتبديل إلى فرع ميزة
git checkout -b feature/add-login main

# العمل في الفرع
git add login-screen/
git commit -m "Add login screen layout"

# Rebase على main الحديث قبل PR
git checkout main && git pull
git checkout feature/add-login
git rebase main

# Push إلى المستودع البعيد
git push origin feature/add-login

هذا المثال يظهر سير عمل نموذجي: إنشاء فرع ميزة من main، عدة commits، وrebase للحصول على تاريخ خطي نظيف قبل الإرسال للمراجعة. هذا النهج يقلل من نزاعات الدمج.

Git Flow ضد Trunk-Based Development

Git Flow وTrunk-Based Development هما استراتيجيتان رئيسيتان للتحكم في الإصدارات تحددان كيف ينظم الفريق العمل مع Git. يعتمد الاختيار على حجم الفريق، وتكرار الإصدارات، ومتطلبات الاستقرار.

Git Flow هو نموذج صارم مع فروع دائمة متعددة: main (كود الإصدار)، develop (التطوير الحالي)، feature/* (ميزات جديدة)، release/* (التحضير للإصدار) وhotfix/* (إصلاحات عاجلة). هذا النموذج جيد للمشاريع ذات دورات الإصدار الواضحة (مثل تطبيقات الجوال بالإصدارات 1.0، 2.0).

Trunk-Based Development هو نهج مع فرع رئيسي واحد (trunk/main) حيث يدمج جميع المطورين التغييرات عدة مرات في اليوم. تُستخدم flags الميزات لإخفاء الميزات غير المكتملة. هذا النهج شائع في تطوير الويب والشركات الناشئة حيث سرعة التسليم مهمة.

Git Flow

Git Flow، الذي اقترحه فنسنت دريسن في 2010، لا يزال أحد أكثر النماذج شيوعًا. ميزته الرئيسية هي الفصل الصارم للكود حسب مراحل دورة الحياة. فرع main يحتوي فقط على كود الإصدار، develop يحتوي على التطوير الحالي، وفروع الميزات تعزل الميزات الجديدة عن بعضها البعض.

فروع hotfix تُنشأ من main للإصلاحات العاجلة وبعد الدمج تُدمج مرة أخرى في كل من main وdevelop. فروع release تُنشأ من develop عندما يكون الفريق جاهزًا للإصدار. يتم إضافة فقط إصلاحات الأخطاء والبيانات الوصفية (الإصدار، البناء). بعد الإصدار، يتم دمج فرع release في main وdevelop. وفقًا لاستطلاع JetBrains (2024)، 37% من الفرق تستخدم Git Flow. نموذج التحكم في الإصدارات هذا يبقى المعيار للمشاريع ذات الإصدارات الثابتة.

# مثال Git Flow: بدء العمل على إصدار
git checkout -b release/1.2.0 develop

# إصلاح الأخطاء في فرع release
git commit -m "Fix login button crash"

# إكمال الإصدار — الدمج في main وdevelop
git checkout main
git merge --no-ff release/1.2.0
git tag -a 1.2.0

git checkout develop
git merge --no-ff release/1.2.0

# حذف فرع release
git branch -d release/1.2.0

يوضح الكود إنشاء فرع release، وتثبيته، ودمجه في الفروع الرئيسية. العلم --no-ff يضمن إنشاء commit دمج، مما يحافظ على معلومات أن التغييرات جاءت من فرع release.

Pull Request ومراجعة الكود

Pull Request (PR) هو آلية يقدم بها المطور تغييرات من فرعه إلى الفرع الرئيسي. PR هو عنصر رئيسي في التحكم في الإصدارات في العمل الجماعي — ليس مجرد طريقة لدمج الكود، بل عملية نقاش ومراجعة وفحص الجودة. في GitLab، الآلية المشابهة تسمى Merge Request (MR)، لكن الجوهر واحد: إعلام الفريق بالتغييرات والحصول على الموافقة.

يجب أن يكون PR الجيد صغيرًا (حتى 300 سطر من الكود)، مركزًا على مهمة واحدة، ويحتوي على وصف لما تم فعله ولماذا. وفقًا لدراسة Google (2025)، PRs التي تزيد عن 400 سطر تستغرق ضعف الوقت للمراجعة، وتقل احتمالية اكتشاف الأخطاء بنسبة 30%. مراجعة الكود (Code Review) هي فحص الكود بواسطة مطور آخر قبل الدمج.

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

المنصات: GitHub، GitLab، Bitbucket

Git هو بروتوكول، لكن للتعاون تحتاج إلى منصة تحكم في الإصدارات توفر واجهة ويب، وإدارة وصول، وCI/CD، وأدوات مراجعة. ثلاث منصات تهيمن على السوق: GitHub، GitLab، وBitbucket.

GitHub هي أكبر منصة مع أكثر من 56 مليون مطور. مملوكة لـ Microsoft، تقدم Actions (CI/CD)، Pages (استضافة)، Discussions، وCopilot. الخطة المجانية تتضمن مستودعات خاصة غير محدودة للفرق حتى 3 أشخاص. GitHub شائع في مجتمع المصادر المفتوحة.

GitLab هي منصة DevOps كاملة مع CI/CD مدمج، وسجل حاويات، وإدارة بنية تحتية. على عكس GitHub، يمكن تثبيت GitLab على الخادم الخاص بك (Self-Managed). Bitbucket من Atlassian متكامل بشكل وثيق مع Jira وConfluence، مما يجعله الخيار للفرق التي تستخدم بالفعل نظام Atlassian البيئي.