دليل Git و GitHub الشامل للمبرمجين: من الصفر إلى الاحتراف مع أبو عمر

بتذكر مرة، كان عنا بالمكتب شب جديد، خلينا نسميه “سامر”، متحمس ومليان طاقة وبده يثبت حاله. أعطيناه مهمة يضيف تعديل بسيط على واجهة المستخدم في مشروع كبير شغالين عليه. بعد كم ساعة، إجا عليّ وجهه أصفر ومحتار، وبحكيلي بصوت واطي: “أبو عمر، شكلها خربت الدنيا… مش عارف شو عملت، بس كل الصفحة الرئيسية اختفت!”.

أخذت نفس عميق وابتسمت، وطمنته: “ولا يهمك يا سامر، بسيطة. ورجيني شو عملت”. المشكلة كانت إنه حذف ملفات بالخطأ وهو بحاول يعدّل الكود. لو كنا بنشتغل بالطريقة القديمة (نسخ ولصق للمجلدات)، كان ممكن الشغل هاد يضيع للأبد ونقضي ساعات طويلة نحاول نصلح المشكلة. لكن بفضل الله، ثم بفضل Git، كل اللي عملته هو إني كتبت أمر واحد في الـ Terminal، وخلال ثواني، رجع كل شي زي ما كان. يومها، سامر تعلم درس أهم من أي كود ممكن يكتبه: أهمية التحكم بالنسخ.

هذه القصة الصغيرة هي جوهر مقالتنا اليوم. Git مش مجرد أداة، هو شبكة الأمان تبعتك، هو آلة الزمن اللي بترجعك لورا لما تغلط، وهو الجسر اللي بتتعاون فيه مع فريقك. يلا يا جماعة، جهزوا فنجان القهوة وتعالوا نتعلم سوا كيف نسيطر على هاي الأداة الجبارة.

ما هو التحكم بالنسخ (Version Control) وليش هو مهم؟

ببساطة، تخيل إنك بتكتب رواية. كل يوم بتكتب فصل جديد. لكن شو بصير لو بعد أسبوع قررت إن الفصل الثالث ما كان منيح وبدك ترجع للنسخة اللي كانت موجودة قبل 3 أيام؟ لو ما عندك نظام، رح تضيع.

التحكم بالنسخ (Version Control System أو VCS) هو نظام بسجّل كل تغيير بصير على ملفاتك مع مرور الوقت. بيعطيك “لقطات” (snapshots) من مشروعك في نقاط زمنية مختلفة، وبتقدر ترجع لأي لقطة بدك إياها بسهولة.

ليش هو مهم؟

• تاريخ المشروع: بتقدر تشوف مين عدّل على شو، ومتى، وليش.
• التعاون: بسمح لأكثر من مطور يشتغلوا على نفس المشروع بنفس الوقت بدون ما “يخربوا” على بعض.
• التجربة بأمان: بتقدر تجرب ميزات جديدة في “فرع” معزول بدون ما تأثر على الكود الأصلي المستقر.
• العودة من الأخطاء: زي ما صار مع سامر، بتقدر ترجع لأي نسخة سابقة بضغطة زر.

الفرق بين Git و GitHub: المحلي والسحابي

هون بصير اللبس عند كتير من المبتدئين. خلينا نوضحها مرة وللأبد.

Git: مدير النسخ المحلي

Git هو البرنامج نفسه، هو الأداة اللي بتنزلها على جهازك. هو اللي بيعمل كل الشغل السحري تبع تتبع التغييرات، إنشاء الفروع، والدمج. كل عمليات Git بتصير على جهازك (Local). لما تعمل `git commit`، أنت بتحفظ التغيير في مستودع Git الموجود على لابتوبك.

GitHub: بيتك السحابي للمشاريع

GitHub (وغيره مثل GitLab و Bitbucket) هو موقع إلكتروني، هو خدمة استضافة سحابية لمستودعات Git تبعتك. فكر فيه كأنه “فيسبوك للمبرمجين”. هو المكان اللي بترفع عليه مشروعك عشان:

• تعمل نسخة احتياطية من الكود تبعك في السحابة.
• تشارك الكود مع فريقك أو مع العالم كله (في المشاريع المفتوحة المصدر).
• تتعاونوا على الكود من خلال ميزات مثل الـ Pull Requests ومراجعة الكود.

نصيحة أبو عمر: Git هو المحرك، و GitHub هو السيارة اللي بتحمل هاد المحرك وبتضيفله كراسي ومكيف وميزات حلوة. بتقدر تستخدم Git بدون GitHub، لكن ما بتقدر تستخدم GitHub بدون Git.

أساسيات Git: أول خطواتك في عالم التحكم بالنسخ

يلا نطبق عملي. افتح الـ Terminal أو الـ Command Prompt عندك.

1. تهيئة مستودع (Repository) جديد

عندك طريقتين تبدأ فيهم:

• إنشاء مشروع جديد من الصفر: روح على مجلد مشروعك واكتب الأمر التالي:

git init

هذا الأمر رح ينشئ مجلد مخفي اسمه `.git` داخل مشروعك. هذا المجلد هو قاعدة بيانات Git اللي رح يخزن فيها كل التاريخ والنسخ.

• نسخ مشروع موجود من GitHub: لو بدك تشتغل على مشروع موجود أصلاً، بتاخد الرابط تبعه وبتستخدم الأمر:

git clone https://github.com/user/repository-name.git

2. دورة حياة الملفات في Git

أي ملف في مشروعك بكون في واحدة من ثلاث حالات رئيسية:

• Modified: عدلت على الملف، لكن لسا ما حفظت التغيير في Git.
• Staged: علّمت على الملف المعدل وحكي لـ Git: “هذا التغيير جاهز للحفظ في اللقطة القادمة”.
• Committed: التغيير تم حفظه بشكل دائم في قاعدة بيانات Git.

الأمر `git status` هو صديقك المفضل. استخدمه دايماً عشان تعرف حالة ملفاتك.

3. الـ Commit الأول: حفظ التغييرات

خلينا نعمل أول commit. أنشئ ملف جديد اسمه `index.html`.

الآن، اكتب `git status`. رح يحكيلك إنه في ملف جديد “Untracked”.

الخطوة الأولى: الإضافة إلى منطقة الـ Staging

عشان تخبر Git إنك مهتم بهذا الملف، استخدم الأمر `git add`.

# لإضافة ملف معين
git add index.html

# لإضافة كل الملفات المعدلة (استخدمها بحذر)
git add .

الآن لو كتبت `git status` مرة تانية، رح تشوف الملف صار لونه أخضر وتحت عنوان “Changes to be committed”.

الخطوة الثانية: أخذ اللقطة (Commit)

الآن حان وقت حفظ هذه اللقطة بشكل دائم مع رسالة توصف التغيير.

git commit -m "Initial commit: Add index.html file"

مبروك! عملت أول commit في حياتك. الرسالة اللي بعد `-m` مهمة جداً. اكتب دايماً رسائل واضحة ومفيدة إلك ولفريقك في المستقبل.

لمشاهدة تاريخ الـ commits، استخدم:

git log

العمل كفريق: الفروع (Branches) والدمج (Merging)

هون بتبدأ قوة Git الحقيقية بالظهور. تخيل إن الكود الرئيسي تبعك (اللي اسمه `main` أو `master`) هو شارع رئيسي نظيف ومستقر. ما بصير أي حدا يجي يشتغل ويحفر فيه مباشرة!

ليش بنحتاج الفروع (Branches)؟

الفروع بتسمحلك تاخد نسخة من الشارع الرئيسي وتعمل “تحويلة” أو شارع فرعي خاص فيك. في هذا الشارع الفرعي، بتقدر تحفر وتعدّل وتجرّب وتضيف ميزات جديدة زي ما بدك. إذا كل شي تمام، بترجع تدمج شغلك مع الشارع الرئيسي. وإذا خربت الدنيا، ببساطة بتهدم الشارع الفرعي بدون ما يتأثر الشارع الرئيسي أبداً.

إنشاء فرع جديد والعمل عليه

لإنشاء فرع جديد والانتقال إليه مباشرة (مثلاً لإضافة ميزة تسجيل الدخول):

git checkout -b feature/login

هذا الأمر هو اختصار لأمرين:

git branch feature/login  # إنشاء الفرع
git checkout feature/login # الانتقال إليه

الآن، أي commit بتعمله رح يتم حفظه في فرع `feature/login` فقط، والفرع `main` رح يضل نظيف وآمن.

دمج الشغل: الـ Merge

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

# 1. ارجع للفرع الرئيسي
git checkout main

# 2. اسحب آخر التحديثات من السيرفر (مهم جداً في العمل الجماعي)
git pull origin main

# 3. ادمج فرع الميزة في الفرع الرئيسي
git merge feature/login

إذا ما كان في أي “تضارب” (conflict)، رح يتم الدمج بسلاسة. لكن الحياة مش دايماً سهلة…

سيناريو عملي: حل التضاربات (Merge Conflicts)

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

السيناريو: أبو عمر طلب من “أحمد” يضيف عنوان للموقع، وطلب من “فاطمة” تضيف نص ترحيبي في نفس المكان.

1. أحمد بيعمل فرع `feature/header`، وبيعدل ملف `index.html` ليصير:

   <h1>Welcome to Our Awesome Website</h1>

   وبيعمل commit و push لشغله.

2. فاطمة (على جهازها) بتعمل فرع `feature/welcome-text`، وبتعدل نفس الملف ليصير:

   <h1>Hello and Welcome!</h1>

   وبتعمل commit لشغلها.

3. أحمد بيعمل merge لشغله في الـ `main` بنجاح. الآن الـ `main` يحتوي على تعديل أحمد.
4. فاطمة بتحاول تدمج شغلها. بتعمل `git checkout main` و `git pull` عشان تجيب آخر التحديثات (اللي هي شغل أحمد). بعدين بتحاول تدمج فرعها: `git merge feature/welcome-text`.

هون Git رح يوقف ويحكيلك: “الله يستر! في تضارب (CONFLICT)”. لو فتحت ملف `index.html` رح تلاقي شي زي هيك:

<<<<<<< HEAD
<h1>Welcome to Our Awesome Website</h1>
=======
<h1>Hello and Welcome!</h1>
>>>>>>> feature/welcome-text

شو معنى هاي الرموز؟

• الكود اللي بين `<<<<<<< HEAD` و `=======` هو الكود الموجود حالياً في فرعك الحالي (`main`).
• الكود اللي بين `=======` و `>>>>>>>` هو الكود اللي جاي من الفرع اللي بتحاول تدمجه (`feature/welcome-text`).

الحل؟

مهمتك كمبرمج هي إنك تقرر شو الكود الصح. ممكن تختار واحد منهم، أو تدمجهم سوا. في هاي الحالة، خلينا نتفق مع الفريق إننا بدنا ندمج الفكرتين:

<h1>Hello and Welcome to Our Awesome Website!</h1>

بعد ما تعدل الملف وتحذف كل رموز التضارب (`<<>>`)، بتعمل حفظ للملف، وبعدين بتكمل عملية الدمج:

# 1. أخبر Git أنك حليت التضارب
git add index.html

# 2. أكمل الـ commit الخاص بالدمج
git commit -m "Merge feature/welcome-text and resolve conflict"

وهيك بنكون حلينا التضارب بنجاح.

GitHub في الصورة: التعاون عن بعد وطلبات السحب (Pull Requests)

الدمج المباشر في `main` على جهازك يعتبر ممارسة سيئة في الفرق الكبيرة. الطريقة الاحترافية هي استخدام “طلبات السحب” أو Pull Requests (PRs).

ما هي طلبات السحب (Pull Requests)؟

الـ PR هو طلب رسمي بترفعه على GitHub، بتقول فيه لفريقك: “يا جماعة، أنا خلصت شغلي على فرع `feature/login`، ومستعد لدمجه في `main`. ممكن حدا يراجع الكود تبعي؟”.

دورة حياة الـ Pull Request

1. ادفع فرعك إلى GitHub: بعد ما تخلص شغلك على فرعك المحلي، بترفعه على GitHub:

   git push origin feature/login

2. افتح Pull Request: روح على صفحة المشروع في GitHub، رح تلاقي زر كبير أصفر بقترح عليك تفتح PR من الفرع اللي رفعته. اضغط عليه، واكتب عنوان ووصف واضح للـ PR.
3. مراجعة الكود (Code Review): هون بتبدأ أهم مرحلة. أعضاء فريقك رح يفتحوا الـ PR ويشوفوا التغييرات اللي عملتها سطر بسطر. ممكن يتركوا تعليقات، يسألوا أسئلة، أو يطلبوا تعديلات. هاي العملية بتضمن جودة الكود وبتعلم الجميع من بعض.
4. الموافقة والدمج: بعد ما الكل يكون راضي عن الكود، بيعطوا “موافقة” (Approve). بعدها، مدير المشروع أو أنت (حسب صلاحياتك) بتضغط على زر “Merge Pull Request” الأخضر الجميل على موقع GitHub.

GitHub رح يتولى عملية الدمج، ولو في أي تضارب، رح يخبرك مباشرة على الموقع.

نصيحة أبو عمر: العودة بالزمن!

أحياناً، بعد ما تدمج ميزة جديدة، بتكتشف إنها سببت مشكلة كبيرة في مكان آخر. بدك تتراجع عن commit معين. إياك تستخدم `git reset` على فرع مشترك زي `main` لأنه بعيد كتابة التاريخ وممكن يسبب مشاكل لزملائك.

الأداة الآمنة هي `git revert`.

# 1. ابحث عن الـ hash تبع الـ commit السيء
git log

# 2. اعمل revert. رح تلاقي الـ hash جنب كل commit (سلسلة طويلة من الحروف والأرقام)
git revert a1b2c3d4

اللي بعمله `revert` هو إنه ما بحذف الـ commit القديم، بل بينشئ commit جديد بيعمل عكس التغييرات اللي صارت في الـ commit السيء. هيك بتحافظ على تاريخ المشروع واضح وسليم.

الخلاصة 🚀

إذا بدنا نلخص كل هاي الحكاية في كم نقطة بسيطة:

• Git هو نظام التحكم بالنسخ على جهازك. GitHub هو بيتك السحابي للتعاون والنسخ الاحتياطي.
• دورة العمل الأساسية هي: `add` (تجهيز) -> `commit` (حفظ محلي).
• استخدم الفروع (Branches) دائماً لعزل شغلك والحفاظ على نظافة الفرع الرئيسي (`main`).
• في العمل الجماعي، لا تدمج مباشرة. ارفع فرعك وافتح Pull Request على GitHub عشان فريقك يراجع الكود.
• لا تخاف من التضاربات (Conflicts)، هي جزء طبيعي من العمل، وحلها بسيط.
• إذا أخطأت، استخدم `git revert` للتراجع بأمان.

أتمنى يكون هاد الدليل مفيد إلكم. تذكروا دايماً، إتقان Git و GitHub مش رفاهية، هو مهارة أساسية بتميز المبرمج المحترف عن الهاوي. استثمروا وقتكم في تعلمه، ورح تشكروني لاحقاً. بالتوفيق يا أبطال! 💪